Anyways question about this pool mode idea. So, when in solo mode, I'm guessing we submit a block followed immediately by another getwork. What is the point in doing it this way when we could simply submit blocks as we do in pooled mode and let long-polling tell us when another block is ready?
If you submitted a block in solo mode, then you presumably solved that block, meaning that a brand new block is ready and waiting for your next 'getwork'. |
|
|
|
A merchant gateway better that MyBitcoin's or MtGox's would be useful.
Can you define "better"? Definitely interested in hearing ideas... |
|
|
|
|
IIRC, one of the goals of the dark pool was to eliminate the need to to write bots that accomplish the same end result as the dark pool (reducing visibility).
Thus, it sounds like people may choose to reduce their visibility regardless of the absence or presence of the dark pool.
I voted "keep it as is", purely because that seems the simplest approach. But I would be just as happy if the dark pool disappeared, and the market was 100% transparent.
|
|
|
|
|
Nice!
I'm glad you added this service. Given that LR->PayPal is very easy, this provides another easy way to BTC->PayPal.
|
|
|
|
|
Note that the wallet's coins are first randomized, and then coin selection is initiated.
|
|
|
|
- Buyer pays $400 immediately with PayPal. If the ticket expires or is canceled, the money is refunded.
Note this has the potential to charge 2x paypal fees... |
|
|
|
agreed, and since he s a big pool, if he did payout too often, he would flood the Bitcoin transfers or wtv and slow everything down.
Not with the new 'sendmany' transaction, designed specifically for pool operators and similar situations. |
|
|
|
Occasionally, poclbm is throwing the following when connected to pushpoold:
Traceback (most recent call last):
File "/home/bitcoin/src/poclbm/BitcoinMiner.py", line 141, in mine
self.sendResult(self.resultQueue.get(False))
File "/home/bitcoin/src/poclbm/BitcoinMiner.py", line 166, in sendResult
d = result['work']['data']
TypeError: 'NoneType' object is unsubscriptable
Traceback (most recent call last):
File "/home/bitcoin/src/poclbm/BitcoinMiner.py", line 141, in mine
self.sendResult(self.resultQueue.get(False))
File "/home/bitcoin/src/poclbm/BitcoinMiner.py", line 166, in sendResult
d = result['work']['data']
TypeError: 'NoneType' object is unsubscriptable
But poclbm works fine via local bitcoind or via the commercial pools. Have you encountered this yet.
What is occasionally? Once a day? |
|
|
|
The difference is, in that situation it's just a bad trader, in the other situation the entire market has to be cleared by a central authority - the corn dealer or company management. If they turn out to be a bad trader the entire market is invalid and it doesn't matter what system[...]
If the "entire market" is a single corn dealer or one lone public company, that may be true. But that's a dumb way to set up a stock system anyway (strawman?). No one in their right minds would want a block chain for every company on NASDAQ -- over 2,000 block chains for that one market. The bitcoin decentralized notary system would be well suited, however, to the task of transferring shares of stock for multiple companies, between untrusted parties. |
|
|
|
Unfortunately the widely used Mysql C API does not support parameterized queries AFAICS.
It does That's useful, thanks. I was looking at this page, and assumed that the "C API Function Descriptions" was a full and comprehensive list. I use bound params with sqlite and postgresql already, but [mistakenly] thought mysql lacked same. * jgarzik goes to update his just-written code... |
|
|
|
Stock is only useful if honored by the company management. If you have to trust them (which you do) they might as well just maintain the share register (which is exactly how it currently works, although most companies outsource the maintenance of the database).
There's no point in using a complicated proof-of-work system to maintain a simple spreadsheet when at the end of the day you're effectively just going to print off a copy and hand it to someone and just trust that they do whatever it says. They might as well maintain it centrally as it's much simpler. There's no value add for this huge p2p network crunching thousands of Ghash/s when at the end of the day someone can just ignore it.
And? At the end of the day, a human can ignore my bitcoins. At the end of the day, a company can ignore my Charles Schwab stock purchase. All they are are ones and zeroes in a computer, just like those dollars my bank claims I possess. A distributed, notarized database of digital tokens has a large number of uses that may extend directly into real world goods. It is readily apparent that value exists in a neutral, distributed entity maintaining a database rather than a single entity (== single point of failure). The only reason the bitcoin network works for bitcoins is there are no external trust dependencies. That won't be true in the case of any of the physical goods trading you described.
Not true at all. Bitcoins would have zero value, if you could not trade them for real-world goods, services and currencies. People trust that the value of their bitcoins will be there tomorrow. That is the mother of all external trust dependencies. |
|
|
|
What would be the difference between coffee and corn?
None, for the purposes of this thread's examples. Why do you think the virtual futures would be priced anywhere near their real world counterpart?
I have no idea what a virtual future is. But if you wanted to trade corn contracts, bitcoin is an excellent notary service for such contracts. Bitcoins and anything like it cannot be backed by something real. If it could, it would have been done.
Everyone who purchases a real-world good with bitcoins, or fulfills a contract with bitcoins, begs to differ. With cryptographically-signed digital certificates, you have as much flexibility as you need, to describe anything in the world. Corporate entities can certainly back digital certificates if it is in their interest to do so. If I was rich and wanted to back bitcoins with gold, there is no reason why I cannot do that. |
|
|
|
See this thread. You might consider offering RPC mining, in addition to payouts. |
|
|
|
I will be giving Mndrix an email. Mt Gox's 7% PP fee is outrageous  . I would have moved some funds over earlier but I was looking for a cheaper/faster/digital way to do it. That's morpheus, not mtgox. And considering the risk of dealing with unknowns who could charge back or dispute their PayPal, 7% is understandable. |
|
|
|
IMO it makes much more sense to add multi-pool support to each mining client. That way it doesn't break long-polling, and you can more easily utilize pool-specific features as they appear (such as using BDP). A meta-pool is an additional point of failure. |
|
|
|
A better option would be to use parametrized queries, which are by definition invulnerable to SQL injection attacks if the DB itself supports them, since the parameters are sent after the query has already been parsed.
Unfortunately the widely used Mysql C API does not support parameterized queries AFAICS. |
|
|
|
If you want things in the block chain to represent shares (ie: you want the management to count your vote come agm time or pay you a dividend) or you want some farmer to deliver you some corn then they (the management or the farmer) becomes the point of failure. You're relying on them.. the fact that there's a block chain that says they should do something is completely irrelevant. They might as well just keep their shares/corn orders in a very ordinary spreadsheet.
That's true for corn, yes, but not stock, which can be traded electronically, automatically and securely. And for corn, that is analagous to selling a coffee or a car for bitcoins. You are relying on an external point of failure. So what if the corn (or coffee) is never delivered. Having one element outside the scope of the project does not eliminate the utility of the bitcoin approach. |
|
|
|
yes, but having each company start their own chain[...]
Who said anything about each company starting their own chain? That's not distributed, nor decentralized. The future of satoshi's proof-of-work technology is a chain marketplace. Multiple chains will exist for different purposes (bitcoin, BitDNS, BitX). Multiple chains will exist in the same competitive space (bitcoins, jgarzik-coins). Wall Street firms may cooperate on a single "Wall Street NASDAQ chain", where all NASDAQ stocks are traded, for example. That would be cooperative and super-strong, yet secure against double-spending (aka naked shorting, etc.) |
|
|
|
If you restart bitcoind with -addnode=173.242.112.53 it will get into a block eventually.
That node will include the ultra-micro transaction even though it includes no fee? Yes. Luke-jr's node is special. |
|
|
|
|
Show Posts
