I would like to trade some Bitcoins for Euro, please let me know by PM who would like to sell some cash tomorrow?
What an excellent idea as an ATM alternative  I should do the same. |
|
|
|
A bitpay contingent is in town, too |
|
|
|
We've set up www.torbroker.info to promote the service to people not yet familiar with Tor. Let us know what you think! I apologize for having to ask this, but, Please remove "BitPay" mention if you would, any comments I make are my personal opinion, and not an official company endorsement. |
|
|
|
|
I'll be in Amsterdam too, for the conference, if anybody has any tech questions related to secure shareholder registries.
|
|
|
|
I look at it like beta software: just iterate through the problems. There are always variables to play with: house edge, further limiting max bets, ... before contemplating shutdown, in my self-interested and biased opinion. Also we have close to 30,000 bitcoin invested so there is still confidence.
+1 When users may vote with their wallets, you always know where they stand. |
|
|
|
I'm quite tempted to just give up on this whole thing. It looks like the site is simply at nakowa's mercy. He's promised me in the past that he won't play any more, but never sticks to his word. So what do I do? Continue to let the investors take these horrific losses?
Several people who have run gambling sites chimed in on reddit, bitcointalk.org and IRC with a similar comment: "1% is too low" And on CYA front: make sure the website text frequently notes the "high risk" nature of gambling and investing, because it is a startup business model and a startup website running on a startup currency The insta-investing feature is nice in general, even if investors lost a shirt or two. Innovative. |
|
|
|
I wanted to say one thing about web-wallets. Please don't host other peoples money; if you really want to build a web-wallet please make it at least client-side encoded so that no important data can be leaked. It would be very easy to build-in a web-wallet to mastercoin-explorer but I'm not doing this for a reason, it will get hacked. If not sooner, then later.
+1 Decentralized is better. Our big central entities of money handling -- pools and web wallets -- all have a history of poor security. |
|
|
|
How about this: make it possible for users to create their own decentralized exchange. - Register a bitcoin address for each shareholder, if not already. This enables the ability to authenticate cryptographically signed digital messages. See this stackexchange answer for a guide. Most bitcoin clients support signing messages. Registering a GPG key for each shareholder is an alternative, though that requires additional software beyond a bitcoin client.
- Publicly declare a bitcoin address and GPG key for official ASICMINER messages.
- Publicly declare an email address for emailing ASICMINER robot
- At the end of every day, ASICMINER robot produces a message listing all shareholders, by key and share count. Attach bitcoin and GPG digital signatures.
- To trade ASICMINER shares, the seller sends a digitally-signed message "transfer N shares to bitcoin address FOO" to the ASICMINER robot.
That is all that is needed on the ASICMINER side: maintain a shareholder registry. changes to the shareholder registry may be both pseudonymous and secure. Then anyone may build an exchange that trades shares. Anyone may trade ASICMINER shares at any time, using this method. Re-posting via quote, given today's BTCT business. Having a publicly auditable share registry is important. |
|
|
|
I humbly suggest that LMB should act proactively and begin tracking shareholders internally and provide means to transfer shares between shareholders on request. It could either be a robot (e.g. the one suggested by jgarzik, maybe with an additional trigger condition in order to allow escrow/arbitration services), or can be done manually with certain limits (one transfer per 10000 shares per week). Pass-throughs can provide liquidity, but would not be the responsibility of LMB. Yes, please For regulatory, technical and security reasons, it is very useful to separate the shareholder registry from the share trading markets. This is also how things work in the "real world." See http://en.wikipedia.org/wiki/Stock_transfer_agentAll bitcoin clients support a "sign message" feature, which may be used like PGP to prove that a shareholder really does control a bitcoin address. Once a provable, secure shareholder registry exists, anyone may set up a market or trade shares privately. If anyone has tech questions, feel free to contact me. |
|
|
|
Note that Jeff doesn't know how MasterCoin protocol works, I think he thinks that it is similar to colored coin approach, but it is not!
Let's not put words into others' mouths, shall we? MasterCoin is almost exactly like my original pybond scheme -- which had nothing to do with colored coins whatsoever. Which is, in turn, similar to Mike Hearn's bond proposal from years ago. The only similarities are higher level concepts of "applying a protocol on top of bitcoin transactions." An earlier proposal would have enabled the attachment of mastercoins (or bonds) to each txout: https://github.com/bitcoin/bitcoin/pull/1809 After much discussion in the community, it was decided that OP_RETURN was superior because it provably enables pruning (thus removing UTXO bloat automatically). Been there, done that, all these problems have already been thought through. (The difference is that with colored coins you have to spend a specific UTXO, but with MasterCoin you can spend any coin.)
Just like my pybond design, which had absolutely nothing to do with colored coins. 1. Plain multisig is a viable option. Bloat prevention can be a policy of client: it should spend these multisig outputs either right away, or after some time.
2. P2SH+multisig is possible and easy to implement, but it isn't clear if it is necessary. In any case, it is easy to add support for it.
3. OP_RETURN offers NO advantages, only disadvantages. it shouldn't even be considered.
UTXO bloat is not a policy of the client, if the protocol is specified to store MasterCoin data in the UTXO set. The quoted message is hand-waving away additional burdens placed upon the network -- and every bitcoin user -- by MasterCoin. It is simple, provable engineering fact that storing data in transaction outputs makes block validation, double-spend checks and other critical consensus operations more expensive. More RAM is used on average. In general, it burdens the entire network. UTXO is our most critical resource currently. We have already made one change in recent times to ensure that UTXO growth is more constrained in the future: https://github.com/bitcoin/bitcoin/pull/2577 Big mining pools also have custom patches on top of PR #2577, that ignore transactions they feel bloat the UTXO set. Even more relevant to MasterCoin, at least two pools that I know of elide transactions that appear to transmit data rather than monetary value, trying to prevent another episode of dumping wikileaks cables into the blockchain. Please work with the community, not against it. The blockchain free-rider problem is very real, and deserves thought. (EDIT: well, OP_RETURN has one advantage: it makes Bitcoins more valuable through monetary deflation Incorrect. All current proposed OP_RETURN schemes set nValue==0, because nobody wants to burn money. Old "sacrifice" schemes have been dropped in favor of miner fees or anyone-can-spend outputs. |
|
|
|
|
We care about bitcoin's curve ;p
|
|
|
|
People need to stop being retarded about havign high rollers gambling on JD.
...
If he cant stop playing on the site, thats only a good thing. Hopefully he will lose most of it back in time.
+1 JD investors want whales to swim by. |
|
|
|
|
Would prefer that the direction of python-bitcoinlib head in the Cython-ish direction, while continuing general pythonization.
Pull requests welcome, including the pythonize branch once its mature.
|
|
|
|
Thanks for the explanation. Wow 5000 shares a second, that brings up a question. At some point will this number get so high that a minimum difficulty be set on the miner's side so so much traffic isn't being sent?
I've long argued that all pools, not just Eligius, should increase their global minimum difficulty. At some point, in my opinion, permitting difficulty-1 shares is not helpful because it does not provide feedback to end-line miners that the overall network difficulty is increasing. CPU miners should be met with slowly increasing pool difficulty, just like the global bitcoin difficulty increases over time. Slow, inefficient miners need that economic feedback from the system. |
|
|
|
They perform two vastly different operations. getblock returns a block minted in the past. getblocktemplate returns a block to be minted in the future. |
|
|
|
It would be really really useful if bitpay would publish the merchant directory. Several users were asking for this months ago, but AFAIK bitpay did not respond with a reason why they do not have a public list. I guess at least 40-60% of merchants wouldn't mind being on the public list.
As BitPay strongly believes in customer privacy, we would at a minimum have to ask each individual merchant, and record their response. Cannot just flip a switch and publish that sort of data... I, too, have longed for a "Bitcoin Business Directory." BBD would be a great resource for users, and need not be limited to BitPay customers. |
|
|
|
CHECKMULTISIG works right now (as far as I know), and arguments against it are largely theoretical: it does bloat UTXO space, but currently it isn't a limiting factor.
It is important that CHECKMULTISIG doesn't do permanent damage, unlike your current approach which does permanent damage.
The way I understand it is that the UTXO space can only bloat when an output is not-redeemable. Since the suggest multisig implementation uses a real/existing publickey it can always be redeemed. This holds true as long as my understanding of multisig outputs is correct. Since people are still worried about bloat I can only come to the conclusion that my understanding is wrong. Making the outputs redeemable is a good and welcome improvement -- but that doesn't eliminate their UTXO storage cost. It just makes that storage recoverable and transferable. The extraneous data continues to be stored in the UTXO set, with this multisig method. One person may redeem a MasterCoin multisig transaction, yes, but the payment target will just create another multisig output that consumes similar amount of UTXO storage space. The data continues to bloat the UTXO dataset, because there is always some multisig output sitting around, waiting to be spent. Question 1:Having a valid public key in a 1-3 multisig is not enough to redeem said output and thus prevent UTXO bloat? So my advice would be:
1. switch to CHECKMULTISIG ASAP
2. make it possible to use OP_RETURN approach
What I (think) to know about OP_RETURN is that it basically creates an unspendable output but at least we know it's unspendable. This is basically a way to destroy coins. Is this correct? And if so is this preferable to having increased UTXO space (if I indeed misunderstand spending multisigs). Correct. OP_RETURN data is provably not spendable. Anything provably unspendable may be eliminated from the UTXO data set. Note! Besides OP_RETURN, there is yet another possibility: P2SH: https://en.bitcoin.it/wiki/BIP_0016With P2SH, the MasterCoin data could be stored in the input scriptSig, as a part of redeeming. This may be unworkable, because the MasterCoin data would only be revealed when you spend a MasterCoin, and not when you receive a MasterCoin. |
|
|
|
URL: http://www.businessinsider.com/intel-shows-pc-using-broadwell-14nm-chips-2013-9Earlier this week Intel CEO Brian Krzanich showed off a Windows 8 PC running a new chip code-named "Broadwell" and promised that devices shipping with it will be coming in 2014.
This chip will use a mind-boggling small architecture, only 14 nanometers (nm) thick, he said during his keynote speech at the Intel Developer Forum conference in San Francisco.
A nanometer is one-billionth of a meter. That's about twice the size of a human blood cell, which is 6-10 nanometers big. It can't be seen with the naked eye.
|
|
|
|
|
Mining is not decentralized, when 3-4 people control >50% of network hash power.
ASIC miners in the hands of the masses mean nothing, when they abdicate their power by mining at a centralized pool rather than p2pool.
Most "miners" play no role in selecting bitcoin transactions. They are simply selling a computing service to the mining pool operator.
|
|
|
|
But this is already the case - if I have both private keys in the wallet, then the balance is displayed by bitcoind. But I'm asking whether a trivial code change would allow me to work with partially controlled multi-sig addresses?
No -- because it's not trivial. |
|
|
|
|
Show Posts
