Topic: [Announce] - OpenPay - Launching Mining Pool (Read 1087 times)

AFAIK, I don't think a mining pool is necessary for this assurance. Once the majority of bitcoind nodes (weighted by hashing power) have the txn in their memory pool (ie, ca. 10 seconds after broadcasting the txn), the txn is pretty well confirmed (even with 0 confirmations)(assuming sufficient txn fees, but even with 0 fees it's pretty solid unless the txn is huge, like 2kb). If there is an orphaned block or two, the nodes will still keep the txn in their memory and hash it into the next block.

There was talk about having p2pool secure ~10second confirmations that it would include a txn in their next block, but I can't dig up the thread right now. Did forrestv ever comment on the feasibility of that? And speaking of p2pool, it gives out coin-base + txn fees, only charging a voluntary donation for development.

tl;dr. I don't think OpenPay needs a pool, but I may misunderstand something

edit: Here is the thread on using p2pool for 10-second partial confirmations: https://bitcointalksearch.org/topic/m.1071988
edit2: What I said isn't secure against Finney attacks, it seems =/

Close but not quite.  When I say no fees to the miner, what I am referring to is the fee that most pools currently take from your mining payout before you ever get it. 

Thus the basic thrust of the argument is, mine on the OpenPay pool and make more money.

Ok, I think I see the basic thrust of the argument now ... mine for OpenPay, get free real-world transactions using OpenPay card ... sounds interesting.

I've been posting while under the weather and so may not be making myself particularly clear.  I apologize and allow me to clarify.
Your are correct, the tx validation does only require a bitcoind, it does not require a pool.  We want the default bitcoind used by the merchant gateway to be always on and always available, hence clustering and running in multiple availability zones worldwide.

The purpose of the pool is to provide assurance to the merchants using the system that their transaction will be included in a block as quickly as possible (one reason for regional sub-pools). 

You are correct in that you could submit the tx to anywhere on the bitnetwork and probably have it included in the blockchain faster, but in general I like the concept of knowing that folks interested in OpenPay are mining the OpenPay transactions and getting the benefit from them.

I also think the concept of sharing in not just the coinbase but any tx fees and not charging the miner any fees is a fair and equitable concept that will hopefully get more folks mining on our pool.

Well that requires 0.0 KH/s.  Not sure where you get the idea that a pool is needed or even useful in any way to validate tx?
We buy 25,000 BTC per month.  We validate all tx using a bitcoind.  Even if you wanted redundancy you could put multiple bitcoind nodes on multiple servers around the world but a pool wouldn't help that either. 

Uptime and failover are the primary reason to not just do it the way you say.  Although honestly the only difference between what you describe and what is planned, is to provide physical redundancy by locating poolservers and their respective bitcoind in various zones globally.  (yes I'm running the pools on AWS infrastructure for now).

As for confirming transactions I'm assuming you meant 500GH/s because I have had a butterfly labs single for over a month and have yet to solve a block.  If it can be done even once a day at 500MH/s then I must have something configured wrong. 

But yes I do mean ensure the tx is valid and not a double spend.

Why would this require you to have a pool? Couldn't you just have a server which has a copy of blockchain, a bitcoind node, and an API that merchants can query?


If by validate you mean "0 confirm" ensure the tx is valid and isn't a double spend no pool is required just a copy of bitcoind.  Merchants do this all the time right now.  If by validate you mean hash into a block doing it in your private pool is likely going to be significantly slower.  Even with say 500 MH/s GH/s you are looking at hours (and sometimes days) before solving a block.

Maybe looking at an official hook-up with deepbit, for example is another option? Deepbit would be able to get transactions out on the network quicker than most I think, but there are other ways to do this and sending a tx to a pool is not necessarily the fastest way to propagate a tx across the network.

Also, as to having your own pool to validate transactions quickly, you'll need to have a large pool, like deepbit, before that becomes a consideration as it depends on how quick they are solving blocks.

I would participate in this pool.  I expect I will be upgrading my mining equipment in October as well.

There is a need with OpenPay to have a trusted source of readily available blockchain information.
It needs to be scalable, reliable and most importantly fast.

The reason for launching a custom pool is that we do not want to have each merchant gateway trying to download and store the entire blockchain.  Unfortunately the current implementation of the OpenPay gateway software, requires access to the entire chain and thus it won't run entirely in a servlet container which was one of our design goals.

Instead we just need to have the ability to quickly query for unspent coins on a given address so we can build the transaction, sign it and get it out on to the network as quickly as possible.  Also having our own custom pool will allow us to validate a given transaction much faster than would otherwise be possible.

Therefore I'm proud to announce that we will be launching a mining pool with absolutely no fees.
All miners will also share directly in the OpenPay network fee (currently 0.1%).
To sweeten the deal further, we will be sharing 100% of the transaction fees for all transaction types amongst the miners.

There will be no need to register and no private information will be gathered. 
Your user id will be the bitcoin address you want your shares sent to, password can be anything or nothing.
Payouts will be automatic and occur upon block discovery and confirmation by the network.

Stay tuned to this thread for more details.