Topic: PULL request #748 : Pay-to-script-hash (OP_EVAL replacement) (Read 12717 times)

I asked that question regarding transactions that you know for sure if they have been spent or not. It was before I wrote this proposal to make sure I didn't misunderstand the protocol. Also, you can partially hash a transaction (in blocks of 64 bytes) until less than 64 bytes of the input section remains, so it would always ocuppy 63+32 bytes at most; but there's no need to complicate things. In my proposal you could just hash the outputs.

Actually, I'm not sure this makes sense without major protocol changes. Currently, if you throw away the transaction inputs you can't prove to other nodes that the transaction was actually buried in the blockchain at the place you claim it was - transactions are hashed as a single piece of data and there's no way of verifying the hash without the entire transaction. So it's not really safe to bootstrap new mining nodes without a complete transaction history including inputs, even if they don't validate the entire chain.

Actually, the pool operators should investigate using p2pool themselves.  I think there are probably plenty of value add services that a pool operator could provide even when something like p2pool is out there (graphing, payout history, monitoring and alerting, etc).  P2pool should also lower the pool operators' costs substantially (not having to maintain as much server and bandwidth or do as much to defend against DDOS, etc).

Which is what i said.


Yeah i have seen it, but i don't remember the Topic ID. Could somebody supply a link ?

p2pool is already averaging almost 2 blocks a day, and getting even faster as it grows. IMO that's plenty low enough variance for the average miner.

So use Eligius, not the three largest pools. Solved.

What fees?

I implemented one a month or two ago, with support for ButterFlyLabs's BitFORCE...

p2pool is nice, but it competes more with solo mining than pools. Short of some breakthrough idea, p2pool can't provide the low variance that the current centralized pools do.

Yes, but if what you say actually happened, all the people mining on those pools would drop out and switch to another pool (or mine solo).  Still, it would be quite disruptive (large scale attacks on pools have shown that it can have a very disruptive affect on network hash power).  A number of months ago someone came up with an idea that would allow individual miners in a pool to craft their own blocks (including any transactions they see fit, but the coinbase would deliver coins to the pool, not the individual miner).  P2pool is probably better though.  Good software on top of p2pool (with pretty graphs, reports and such) might help in attracting more people to it.

Yes.

I'd love so see a bitcoin client with p2pool-technology built in; bring back the "generate coins" option!

But... that will take a while. If I was a pool operator, though, I'd be thinking about other bitcoin-related businesses where I could use my expertise (the pool operators deserve a lot of credit, they've had to deal with DOS attacks, keeping their wallets safe, servicing hundreds or thousands of customers banging on their servers constantly, etc).

Whoah, this went definately too easy.

I mean, how decentralized are we, really ? What if US took over 5 biggest pools and having ~65% the next day we would have massive scale attacks on the network ?
That would be a disaster. Perhaps a temporary one, but still a disaster. How long do you think it will take before they try something like this ?

Shouldn't we all push for decentralized pools, like P2Pool ?

Eligius is on board for BIP 17.

I'm for p2sh and my pool will provide /P2SH/ in coinbase in two days.

Edit: Actually I want to support Gavin with his effort, but I'll eventually support BIP 17 if there will be broader agreement on it and it became "official" replacement.

You can do it with Eligius. Just be sure to pay the appropriate fee.

I'll be doing a BIP 17 P2SH test as soon as I'm done integrating it with git master (the hard part is undoing the BIP 16 mess).

Can a pool operator please mine a block containing a P2SH transaction on main net and redeem it. I'd like to a do some P2SH preperation, but don't have Testnet setup.

Be careful with such artificial transaction fees, because it's not really the number of transactions that a given transaction begets that is the problem, but the total bandwidth consumption and computational demand upon the network.  In the near term, a single transaction with numerous outputs is more efficient most of the time.  This is because, with a transaction fee that is higher simply because of the actual demands of resources, a send-to-many transaction is less burdensome in the short term, and the longer term results of future transactions are unpredictable.  As an example, it would generally be vastly less resource intensive for a large corporation to use send-to-many transaction for weekly payroll then to produce a standard two-output transaction for each employee.  In either case, however, what the employees do with those transactions next are not dependant upon how they are paid.  Such large send-to-many transactions take up a lot of space and bandwidth, but remain relatively efficient if compared to the space and bandwidth that those same outputs would have produced individually.  We can assume that the send-to-many transactions will have a much longer 'lifespan' in the blockchain before they can be pruned, but we can also assume that some percentage of the individual transaction would have lasted as long.

This is one of the things I find very cool about bitcoin.  You can have a kind of rolling history.  Only a relatively small number of nodes will need to retain the full history (though more than one just in case some bad fate befalls it).  And this is sufficient since anyone at any time could download and verify that entire history from the beginning.  All the other nodes just maintain an in motion picture of the network, allowing ancient history to expire off the back end.

Another related thought that I've had is that transactions with more outputs than inputs should somehow cost more since they increase the overall number of transactions that nodes need to retain for verification purposes (and transactions that have a fewer number of outputs than inputs decrease the number of transactions that the network needs to retain).

That's exactly what I thought.

Once transactions are validated and buried "deep enough" in the blockchain you can forget their inputs, because the inputs are only needed for validation.

... although SOMEBODY on the network should remember them, in case I-don't-trust-anybody nodes want to validate the entire blockchain.

Well...  If you validate it yourself, and can be pretty sure that your database won't get corrupted or attacked, you could toss it, maybe.  I would need to read the chaining rules again to be sure.  But I would be very reluctant to prune that aggressively, even if the blockchain growth somehow manages to severely outpace the size growth of cheap hard drives.