Topic: 0 confirmation - signed by miner? - page 2. (Read 3558 times)

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)

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 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

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.

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.

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