Costia (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 01, 2012, 03:02:52 AM |
|
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 ![Sad](https://bitcointalk.org/Smileys/default/sad.gif)
|
|
|
|
Revalin
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 01, 2012, 03:31:17 AM |
|
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.
|
War is God's way of teaching Americans geography. --Ambrose Bierce Bitcoin is the Devil's way of teaching geeks economics. --Revalin 165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
|
|
|
FreeMoney
Legendary
Offline
Activity: 1246
Merit: 1016
Strength in numbers
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 01, 2012, 06:07:11 AM |
|
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.
|
Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
|
|
|
ByteCoin
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 01, 2012, 12:11:43 PM |
|
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
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
|
|
|
|
Costia (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 01, 2012, 02:26:56 PM |
|
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.
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.
|
|
|
|
Maged
Legendary
Offline
Activity: 1204
Merit: 1015
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 01, 2012, 06:06:00 PM |
|
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.
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. 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)
|
|
|
|
hannesnaude
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 169
Merit: 100
Firstbits : 1Hannes
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 01, 2012, 07:19:26 PM |
|
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?)
|
|
|
|
Costia (OP)
Newbie
Offline
Activity: 28
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 01, 2012, 07:27:34 PM |
|
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.
|
|
|
|
hannesnaude
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 169
Merit: 100
Firstbits : 1Hannes
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 01, 2012, 08:27:03 PM |
|
But where's the incentive for a miner to do this?
none what is the incentive today of miners to include transactions at all? the 0.1BTC transaction fees? 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. the incentive would be to keep the network working properly, otherwise bitcoins will lose their value.
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.
|
|
|
|
dustintrammell
VIP
Full Member
Offline
Activity: 156
Merit: 103
Cleverly disguised as a responsible adult.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 09:14:39 AM |
|
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.
|
Dustin D. Trammell Twitter: @druidian PGP: E0DC F55C 9386 1691 A67F FB18 F6D9 5E52 FDA6 6E16
|
|
|
P4man
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 09:25:51 AM |
|
so if you got a signed reply from 40-50% of the hashpower -
But how do you know something represents 40-50% of the hashpower? AFAIK, the only way of knowing is solving blocks.
|
|
|
|
caveden
Legendary
Offline
Activity: 1106
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 09:49:43 AM |
|
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
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". 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.
|
|
|
|
FreeMoney
Legendary
Offline
Activity: 1246
Merit: 1016
Strength in numbers
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 10:16:49 AM |
|
so if you got a signed reply from 40-50% of the hashpower -
But how do you know something represents 40-50% of the hashpower? AFAIK, the only way of knowing is solving blocks. 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.
|
Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
|
|
|
caveden
Legendary
Offline
Activity: 1106
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 10:43:11 AM |
|
Pool operators can embed signatures in their blocks if they want. It would be more complicated to organize such scheme on P2Pool though...
|
|
|
|
Revalin
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 10:51:28 AM |
|
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. 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, But where's the incentive for a miner to do this? Offer an extra tx fee for a miner who includes the transaction in a block after making a signed promise. If you take 1 BTC and create two transactions, both spending it to different addresses, then send out both transactions simultaneously 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. But how do you know something represents 40-50% of the hashpower? AFAIK, the only way of knowing is solving blocks. 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.
|
War is God's way of teaching Americans geography. --Ambrose Bierce Bitcoin is the Devil's way of teaching geeks economics. --Revalin 165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
|
|
|
caveden
Legendary
Offline
Activity: 1106
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 12:19:42 PM |
|
But where's the incentive for a miner to do this? Offer an extra tx fee for a miner who includes the transaction in a block after making a signed promise. 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.
|
|
|
|
Revalin
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 12:42:39 PM |
|
It can also be the other way around. Miners publicly offer to "support" transactions which contain a minimum amount of fee. That's perfect. I love it.
|
War is God's way of teaching Americans geography. --Ambrose Bierce Bitcoin is the Devil's way of teaching geeks economics. --Revalin 165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
|
|
|
realnowhereman
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 01:29:18 PM |
|
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.
|
1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
|
|
|
ByteCoin
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 03, 2012, 01:21:48 PM |
|
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.
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
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 03, 2012, 01:33:25 PM |
|
so if you got a signed reply from 40-50% of the hashpower -
But how do you know something represents 40-50% of the hashpower? AFAIK, the only way of knowing is solving blocks. 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.
|
|
|
|
|