Bitcoin Forum

A client can estimate the hashing power of a miner by looking at the payouts of newly generated blocks.
He can then send his transaction like normal, but get instant replies from miners.
If a miner decides to include the transaction in his next block he will send a signed version of the transaction - signed by the private key of his payout address + attach the public key
The client can listen for these "signed by miner" transactions, verify that the public key hashes to payout address and matches the sig, then estimate the total hashing power that "promised" to include his transaction in the next(or later) block

was this already suggested?
too tired to think of security holes right now :(

The major problem I see is that a corrupt miner could make false Promises.  I don't think that's a show stopper though.  

Just restating it how I envision it - correct me if I'm wrong:

Alice makes a payment to Bob and transmits the transaction to the network; transaction is flooded;
All active miners sign it as a Promise to mine it; the signatures are flooded;
Bob receives the payment transaction and confirming signatures;
Bob waits until he has a reasonable number of Promises before delivering goods.

Each block would have a miner's pubkey that can be used to sign future Promises.  If the keys used in say 3000 of the last 5000 blocks then sign the transaction, it's basically good - anyone who could make those signatures and then fail to mine the transaction into the next block could just as easily make a 51% attack.

We would have to decide on how large a sliding window to use.  The amount of traffic generated by allowing every miner who's ever mined a block to make a Promise would become unwieldy.  Nodes should stop relaying Promises signed by pubkeys that haven't been in the chain recently.

I suggest making the "Percentage of Promise" be (the sum of difficulties of blocks with keys that sign the transaction) / (the sum of difficulties of all blocks in the sliding window).  That would prevent some miners having undue weight when the difficulty changes.

Just at first glance I think it works.  Great idea.

Is it a promise to reject any block contains a different transaction with the same inputs? That might leave the miner off the real chain forever no? But otherwise what does it matter? They'll mine the tx unless another gets in first? Not much help really.

It would really be an insurance that if the chain confirmed a block containing a transaction spending the same inputs in a different way then the miner would pay the outputs himself instead.

With a sufficiently descriptive scripting language, issuance and enforcement of the insurance could be "automatic".

ByteCoin

its not a promise to reject, but a promise not to mine a conflicting transaction. and to include your transaction in a mined block (so even if a block is orphaned due to other reasons, the transaction will still be included later)
so if you got a signed reply from 40-50% of the hashpower - you can be quite safe that a competing transaction won't end up in the longest blockchain.
it's not 100% safe, but it's a good indicator.
But i think it has the potential to flood the network when there are a lot of transactions.maybe there should be a way to consolidate miner sigs. so if a client sees 2 verifications it will send out 1 packet with both sigs, so after a while you will have only 1 confirmed transaction being flooded in the network with a long list of sigs. and maybe  add a timeout - you can only send/propogate a certain signed transaction once every 2 seconds - you will have more chances hearing new sigs in that time.

It can be made into a promise to reject. Of course, no miner would make that promise on their own. However, if you get the initial promise not to mine conflicting transactions, you could then use that promise from 50%+ to prove to the miners that it is safe to reject, although I suspect that a decent fee would be involved in that. However, it could work to make 0 confirmation transactions completely safe after a few seconds (after you contact the miners and get enough support to have them to reject conflicting blocks)

But where's the incentive for a miner to do this? Perhaps it is cheap enough to do this today, but as the tx volume grows it quickly becomes a significant cost, both in terms of computation power and bandwidth. And what is the punishment if a miner signs a tx and then reneges and mines an alternate version (perhaps because it includes a larger tx fee?)

none
what is the incentive today of miners to include transactions at all? the 0.1BTC transaction fees?
the incentive would be to keep the network working properly, otherwise bitcoins will lose their value.

Some miners still include zero fee txs today because it is not a bottleneck in their processing. When it becomes one you can be assured that only txs with fees that cover the cost of processing will be included. Similarly you can expect miners to voluntarily sign txs for you today at no cost. But in an anonymous system where you have no power to punish a signer who reneges, the signature is not worth anything. And even if it was, it will go away when miners become CPU bound. That's the way of the world.

Nope. The network is working just fine. If you could make 0-confirmation transactions safe (and this proposal won't) that would add value, but bitcoin certainly won't lose value without it.

If you take 1 BTC and create two transactions, both spending it to different addresses, then send out both transactions simultaneously to half your peers each, you could likely get two (or more, expand multi-spends to as many peers as you have) groups of mining peers on the network to promise to include each individual transaction in direct competition with each other as the announcements would arrive across the network at varying times.  As the spender, you are attempting multiple transactions at once and hoping that the recipients deem the number of promises they receive for their individual transaction to meet their threshold for trustworthiness.  As the recipient, this threshold would likely need to be a large majority of the network mining peers so as to ensure that even at the minimum number of possible double-spend transactions, two, you are reasonably sure that your transaction will be the one to be included in the block-chain first, thus preventing any duplicates from double-spending what you've received.

However I guess if the recipient client detects duplicate transactions on the network after a short given period of time (far less than waiting for a block to be found), destined for multiple different recipients, it could just default back to waiting for block confirmations.

But how do you know something represents 40-50% of the hashpower? AFAIK, the only way of knowing is solving blocks.

And if this works out, it pretty much solves the tragedy of the commons scenario for transaction fees. People with interest in not having their transactions double spent could buy such form of insurance.
The question that stays in the air is whether the risk of suffering a double-spend is high enough to motivate people to buy such insurances. But I guess that the answer to that is that, if the risk is not the high, maybe there's not so much need for mining power either. Safer is not always better, you have to take the costs into account.

For example, a miner could send all generated coins to the same address and sign the tx with that address. Likely a more elegant way exists. If you mean you don't know if they'll have X hashing power in the future, yeah, of course.

Pool operators can embed signatures in their blocks if they want.
It would be more complicated to organize such scheme on P2Pool though...

I don't care for this twist myself.  Funding the insurance would be complicated.

Rather than getting dinged because some net split resulted in you signing off on the wrong half of a double-spend, I would prefer the motivation to be to get a reward for including the transaction as promised,




Offer an extra tx fee for a miner who includes the transaction in a block after making a signed promise.




The classic double-spend.  The miner can wait a few seconds before making the promise to ensure there are no conflicts; and the recipient can watch for it as well.  This will catch 90% of such attempts.

The rare exception will be where the network is severely split and the double-spender is able to exploit it to his advantage.  Someone selling a cup of coffee won't be worried about such cases, but a business subject to fraud - a wallet service for example - could simply wait until they has signed promises from 75% of the network before accepting the transaction.




Each time a miner signs a block they include a copy of a pubkey.  The merchant gets the last 1000 pubkeys from the blockchain.  If they want 75% of hashpower signing off, they wait until they have 750 signatures (or fewer: many of the blocks will have the same pubkey since most blocks are solved by a handful of pools; a pool which solved 150 of the last 100 blocks only needs to make the signed promise once).

It doesn't prove that it's approved by 75% of hashpower online right now, but 75% of the hashpower for the last 1000 blocks.

It can also be the other way around. Miners publicly offer to "support" transactions which contain a minimum amount of fee.

I like where this is going. It seems a cheaper alternative to the "expensive green address" proposal I've seen before, and it is decentralized too.

That's perfect.  I love it.

How to give a miner an incentive...

Let's say I'm a merchant.  I make a sale, and see the customer's transaction broadcast.  I want to ensure it gets into a block as quickly as possible.

I could (if the client allowed it) broadcast a new transaction based on that not-yet-confirmed transaction, with a fee.  Miners would then want to include the customer's transaction since that's the only way that my fee-paying transaction to them would be claimable.

With the current architecture, it's difficult to accept "instant" payments securely. It's unlikely that a merchant will individually have the infrastructure to check the propagation of a transaction so they can't even manage the risk of a double spend attack succeeding.

Someone with good (contractual?) relationships with the major mining pools could offer insurance at a rate probably around a small fraction of a percent of the transaction value. It's much easier for merchants and customers to account for a small constant insurance cost than large double-spend losses.

ByteCoin   

If miners (or at least large miners signed blocks w/ a private key then by looking at block signatures over the last say 7 days   would give you a decent estimate of hashing power.  Of course today no miner's do such a thing but if having X hashing power (that could be provable in realtime) was worth some economic value it would be relatively easy to implement.

That would work however the attacker could do the same thing.  The double spend could contain a larger transaction fee and thus mining algorithm that is opportunistic would choose it for your transaction + transaction w/ fee sequence.

Given the "profit margin" for a double spend is potentially higher the attacker will always be able to "out-fee" a legit operator.

No miners would voluntarily run a system that does this.  They may get higher fees, sure, but they make the system vulnerable to double spends by accepting later transactions to different destination addresses with higher fees.  By making the entire Bitcoin network vulnerable to double spends, they ensure that the higher fees they get are worth nothing.

A miner could use the fee in a "dependent transaction" to increase the speed at which the original transaction is included in a block, but would have to put constraints on rebroadcast transactions with higher fees.  Namely, the constraint would be that up to one output may have its value changed and up to one input may be added to increase transaction fee.  Otherwise, you open up double spends.

I think you forget that a double spend isn't "spend" wait ungodly amount of time then "double spend".
It is a near simultaneous release of two transactions. 

You are assuming the good transaction hits first.
What if the bad one does?
What if they hit at nearly the same time (most pools queue up transactions)?

Then the merchant should be able to see that they're being double-spent against and not give up the merchandise.

Sweet you solved the 0-confirm double spend problem.  Strange nobody thought of that solution yet.


... or maybe it still isn't solved.  BTW a 0-confirm double spend is rather difficult to pull off but it isn't impossible.  You stating the difficulty of the attack isn't a solution.

If you ask me, the reason - in part - that Bitcoin has been successful so far is that there are monetary incentives to keep the system running by the rules. If we start to depend on miners "doing the right thing" because we assume that they are concerned with the long-term survival of Bitcoin, I'm not sure things will continue to go well. Looking at the average human, it's hard for me to see that we are all that concerned with the long-term sustainability of important things that we depend on. I don't  think miners (being human beings) would be either.

This is an interesting discussion though. The 0-confirmation double spend problem would definitely be a valuable one to solve. I do think it would have to involve some form of centralization though. Not that this is necessarily a bad thing though, since no one would be forced to go this route.