Both of these make P2Pool easier to use; the eventual goal is being able to run P2Pool on the same hardware miners use, such as a Raspberry Pi, though that would likely require a laborious rewrite in C++ or another compiled language.
My current progress on this: I have a piece of software talking to bitcoind and augmenting blocks with UTXO merkle branches, feeding that to another piece of lightweight software that can trustlessly verify the blockchain, while holding O(1) state. I have a good idea about how the non-linear sharechain will work, but implementing that hasn't started yet.
- Why a UTXO proof vs. a TXO proof?
- How do you see these p2pool nodes starting up? Will they get the UTXO set from another node, or verify some or all of the blockchain themselves?
- Have you thought about what happens during a 51% attack? What if p2pool has a larger share of hashing power than it does now?
|
|
|
|
Thanks. I realised after I wrote that that Shamir shares *secrets* not signatures so that's no good (I guess the clue was in the title  ). Could something be hacked together with CoinSwap? I don't think so. The threshold sig stuff sounds pretty far along; for now 15/20 isn't such a bad limitation IMO. |
|
|
|
Peter,
Is there any prospect in the future for these limits to be increased? It seems to me there are quite a lot of applications for larger than 15.
Or if that just leads to unacceptably big transactions even with appropriate fees, is there some way that I haven't quite thought of to combine multisig keys to get bigger consensus mechanisms? Or is it possible to use some kind of Shamir's secret sharing idea? (I only know the idea vaguely, not sure how it would work in practice).
Btw, nice work on the site guys.
I'm at the Financial Crypto conference right now and actually just talked to a guy who claims to know of a researcher who has come up with a n-of-m threshold signature scheme that is compatible with existing Bitcoin signatures. Hopefully this will pan out - if it does you'll be able to do secure multisig without a single-point-of-failure (as Shamir's secret sharing does) with transactions and addresses that look identical to standard ones and are the same size as standard transactions. I didn't ask if there were any limits on how many keys could be combined, but there probably aren't. |
|
|
|
|
edmundedgar: Mind re-posting this to the bitcoin-development list? I think it'd get more attention there, and the discussion would be archived more widely. It's also a fundamental question to a lot of protocols.
|
|
|
|
I'm not sure you can really blame Satoshi for this. Either OP_CHECKSIG is useless, or any changes to it mean a hardfork anyway. Consider an "upgrade" that your node is unaware of. Your node will see it as an invalid signature. You can either accept all invalid signatures (which makes it pointless to check), or you can be forced to upgrade your software to keep up (which is what a hard fork is).
Contracts can be fixed with a softfork, bumping the block version to 3 and requiring that all signatures in version 3 blocks be in minimized form.
Nope. If Satoshi had implemented OP_CODESEPARATOR correctly, without making it automatically get inserted into the concatenated scriptSig and scriptPubKey and with the existing OP_RETURN fails the script design you could upgrade SIGHASH with new, useful, flags by having them check a signed hash against other conditions. FWIW this is one of the things that makes me think Satoshi released bitcoin prematurely and on a deadline. I doubt he ever actually prototyped any of the things the scripting system could have been used for prior to release. |
|
|
|
yes. I restored the full version with header files in the bitcoin0.1 folder. it looks like a small auction system as Mike said above. it's only 260 lines. https://github.com/benjyz/bitcoin0.1/blob/master/bitcoin0.1_version/market.cppso there are 3 versions in the repo (probably should be separate trees): * the root folder only contains the main files for study purposes * the nov08 version * the full 0.1 version with headers and unused parts like the market.cpp Awesome thanks! Where exactly did you get this code from? Might be good to add some notes about the source of it in the README. If you have, say, zip files good to put them in the repo for archival purposes. (this is important history after all) |
|
|
|
I've got the 0.1 version and the nov08 version on github. blogs are not a good CVS. https://github.com/benjyz/bitcoin0.1/tree/master/nov08the main files from the 0.1 source code in 7000 LOC. 2660 ./main.cpp 1127 ./script.cpp 1020 ./net.cpp 604 ./db.cpp 554 ./sha.cpp 373 ./util.cpp 265 ./irc.cpp 264 ./market.cpp 6867 total market.cpp? I don't see that in your repo - do you actually have a copy of it? |
|
|
|
Well, I just find a way to save it.
Let's have a new SIGHASH type called SIGHASH_ANYUTXO. Signing with this tag means that the signer would allow the redemption of any UTXO of the same address. So the signer don't need to specify the hash of the UTXO. The signature is valid no matter how the txid is changed. As long as the signer is not reusing the address, that would be safe.
Any comment?
That's what I've been saying for ages... though it'll have to be implemented as a new CHECKSIG operator due to Satoshi screwing up upgrade possibilities in CHECKSIG. |
|
|
|
Perhaps I'm missing something - it seems to work fine for me using 20 uncompressed [dont recall if I've tried having all 20 required signers yet - trying now]. I understand this code somewhat[not enough]; Please elaborate if possible & let me know what lines are P2SH - I thought this was a bit different. I'm digging through it blindly. Incidentally, i thought the p2sh git referenced "+22 signatures" https://github.com/bitcoin/bips/blob/master/bip-0016.mediawikiThat's "signature operations", not signatures. SigOps is just a metric used to restrict the amount of CPU time processing a block takes as an anti-DoS measure - it's got nothing to do with the actual number of signatures. You'll find you can create that P2SH address with the Bitcoin RPC interface, but you can't actually spend from it succesfully. Kinda misleading really - if you could do up a patch to fix that and make createmultisigaddress raise an error that'd be great. |
|
|
|
If anything, not being forced to curate the "garbage dump" in addition to the Bitcoin blockchain would enable more people to run Bitcoin full nodes. I understand that a lot of participants are unwilling/unable to fully verify, but hijacking the Bitcoin blockchain for a zillion other often unrelated and often unwelcome applications just makes the problem worse.
But again, in the merge-mining for proof-of-publication case, unless mining hashing power is more decentralized the merge-mining is not proof of anything, resulting in insecure applications. I get your point though about parasitic users being incentivised to be, well, parasitic.
Also, even if there is ultimately no technical means to prevent blockchain hijacking, this doesn't mean social pressures can't work to some useful degree. Well-respected developers being vocal about it at the very least this gives less abusive alternatives a PR advantage, or can correct the most egregious abuses - like e.g. mastercoin's initial use of non-prunable outputs.
You realize that the dev's involved appear to have managed to lose that social respect overnight by making an about-face on the idea of OP_RETURN? You may not think that within this small community, but within the community of people making use of data and metadata-using transactions they have. Just a week or two ago I was arguing with someone - a paying client - that the OP_RETURN thing was certainly going to be released and they should go to the effort of using it for their application. Well, looks like I was wrong, and when I talked to them again earlier today their plan is to stick with what they had written initially and use UTXO-bloating outputs. TXO commitments are just a small part of solving scalability - they only help with long-term storage and actually make bandwidth scalability significantly worse. They do appear to be a good approach to blockchain sharding - tree-chains makes use of them - but the people who have been claiming they represent some scaling breakthrough misunderstand the technology.
Right, I calculated a little while back something like a ~7 fold increase in bandwidth (for authenticated prefix trees), but my understanding was that they are useful because they enable partial verification/fraud discovery and distributed block construction, which spreads the increased bandwidth load over a much larger number of participants. Is this a misunderstanding? Or just an overestimation of the number of extra participants? Yup - they don't make distributed block construction possible by themselves. Which is a really serious problem actually as what could happen is they just act to paper over the scalability problem and leave us in a situation where it lets a larger block size or similar look scalable, which further centralizing control of mining. I gotta admit, I was a bit reluctant to publish the idea for that reason initially, but decided it was a strict improvement on UTXO commitments so went ahead. |
|
|
|
If you think merge-mined chains represent proof-of-publication in a world of large pools, you misunderstand what the idea is. Fundamentally merge-mining is insecure without the participation of at least a very large fraction of the mining hashing power, which negates the scalability argument for merge-mining.
Don't forget about all the non-mining full nodes that would avoid having to carry the extra burden. Miners are getting financially rewarded for it, so it's much less of a problem for them. And hashing costs dominate up to pretty large scale anyway. That's the problem! If miners are the only ones with the data, then it's not proof of publication. Of course, this shows a flaw in Bitcoin, but at least for now we've been able to paper over that flaw... In fact, with some cleverness I suspect I could make the entire Mastercoin and Counterparty protocols be purely hash based and unblockable by generic mechanisms; I should put some thought into this...)
Well if the system can be hijacked, then I'm sure some clever people will do it, and this will make all the previous talk about ethical blockchain usage moot. Exactly - I know it can and will be hijacked. #bitcoin-wizards is where this has been discussed. Working on a more formal paper for tree chains as well. I prefer not to discuss ideas here - much better to discuss ideas on open mediums like email lists that are archived by multiple entities.
Thanks, I saw the tree chain discussion, but haven't read through it carefully yet. Are you not interested in the MMR TXO commitments idea anymore? Looking forward to the paper, I hope you finish it before you begin working on the blockchain hijacking mechanism  TXO commitments are just a small part of solving scalability - they only help with long-term storage and actually make bandwidth scalability significantly worse. They do appear to be a good approach to blockchain sharding - tree-chains makes use of them - but the people who have been claiming they represent some scaling breakthrough misunderstand the technology. Incidentally, I'm inclined to drop the "MMR" from the approach - for TXO's as opposed to timestamping just using a variable height sparse merkle tree indexed by insertion order is simpler and results in pretty similar proof lengths as with MMR's. As for what I'm working on... everything at once, as usual. All this tech interrelates - I probably wouldn't have thought of the proof-of-publication theory if I hadn't been thinking about Mastercoin at the time. |
|
|
|
Enter the uncompressed public keys of all the participants, to create a multi signature address. Maximum of 20 allowed.
This is incorrect actually. While the underlying CHECKMULTISIG opcode can support up to 20 pubkeys, P2SH has an additional limit of 520 bytes for the scriptPubKey. That gives a size-dependent maximum of 15 compressed pubkeys, and just 7 with the larger uncompressed keys. |
|
|
|
I don't mean to; there are definitely interesting things that can be done. I just question whether it's necessary to do them on the Bitcoin blockchain. A truly symbiotic application seems like it could work perfectly well using a separate merged mined chain, and atomic cross chain trading. (And if the application is competing with Bitcoin, then all the more reason to keep it the hell off the Bitcoin blockchain, if possible.)
If you think merge-mined chains represent proof-of-publication in a world of large pools, you misunderstand what the idea is. Fundamentally merge-mining is insecure without the participation of at least a very large fraction of the mining hashing power, which negates the scalability argument for merge-mining. Obviously pretty much nobody would object to that example. Yet consensus seems to be that using the blockchain for completely arbitrary data dumps is a bad idea. So yes the line is blurry, but that doesn't mean it doesn't exist or is safely ignored.
Even if there is consensus about that, which I myself am a solid counter-example, there isn't consensus about what exactly arbitrary data is. This implies a rejection of any defined purpose for the blockchain: "it exists for whatever the highest bidders want to use it for". For example, crowded out users that just want to transfer bitcoins back and forth would IMHO be rightly upset by this kind of transformation.
Equally those who had been putting a lot of effort into decentralized finance will be rightly upset by this kind of transformation. Which is why my advice to them is don't get sucked into the hype - blocking data in the blockchain is non-trivial and their applications don't have much to worry about. Furthermore blocking proof-of-publication/timestamping for hashes is outright impossible, and for many of these applications (e.g. colored coins) hashes is all you need. In fact, with some cleverness I suspect I could make the entire Mastercoin and Counterparty protocols be purely hash based and unblockable by generic mechanisms; I should put some thought into this...) I hope so! Better fundamental scalability is certainly the ideal solution. Since I like to keep up-to-date on these topics, what is your current favoured way to go here? Just the name of the proposal is fine, I can search through the chat logs/forums to get the details. Thanks.
#bitcoin-wizards is where this has been discussed. Working on a more formal paper for tree chains as well. I prefer not to discuss ideas here - much better to discuss ideas on open mediums like email lists that are archived by multiple entities. |
|
|
|
You don't need OP_RETURN to store data, particularly hashes. The idea being it was to encourage people to store data in the least harmful way possible in outputs that can be obviously pruned; like it or not putting data in the blockchain is useful so people will do it, and there's no good way to stop people from doing so.
As you pointed out in a recent post*, P2SH^2 on the scriptPubKey side and MASTs on the scriptSig side would work to keep the blockchain from becoming a garbage dump. Since both of these changes would be very good for both scalability and privacy, I don't understand why you were so quick to write them off as unlikely. "Garbage dumbp" Please, don't write off useful applications for proof-of-publication so quickly. Heck, just the other day I realized how it could be used to create decentralized digital asset exchanges with cryptographically verifiable pricing that was inherently resistant to market manipulation: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03892.htmlOf course, once data is prunable, it's no different than any other transaction in terms of impact on the system - you're still paying fees on the exact same basis as doing any other transaction.
The problem is that non-Bitcoin applications compete for scarce block space, driving up the cost of transactions for Bitcoin users. As you know, this cost is either felt in the form of fees, or increased centralization if the block size is simply raised to accommodate. I don't think it's unreasonable to say that Bitcoin users ought not be burdened by arbitrary demands of its blockchain. What is or isn't a "Bitcoin application" is open to debate. I certainly think decentralized finance has the potential to be valuable, and it will be quite concretely based on Bitcoin as a medium of exchange in actual applications. More to the point, if I wish to, say, use a multisignature protected wallet, I'm creating transactions that take up significantly more blockchain space than those that don't. Of course, I pay for that space in fees, driving up costs for all Bitcoin users... So am I wrong for doing that? You mentioned it being better to just focus on the root of the problem - fundamental scalability - but the potential solutions I've seen proposed by you seem like very radical changes (far more so than P2SH^2 or MASTs), and the conservative approach appears to be to protect the blockchain from abuse to the greatest extent possible at least until a particular scalability upgrade has been 1) implemented, 2) well-tested, and 3) widely agreed upon.
Regarding OP_RETURN though, I agree that it's the proper way of doing damage control (though I worry that it sends the wrong signal to users that this usage is acceptable, and not abusive, and will encourage more of it), but only while P2SH^2 and MASTs are not yet implemented.
My worry is if we don't stick to a strict market-based allocation of proof-of-publication security we're going to see an acceptance in this community of rationing it based on perceived value. Frankly, this is much like net neutrality debates - I believe in applying freedom of choice and non-judgemental market principles rather than having a small group of devs and pool operators decide what is or isn't the valid use of the Bitcoin blockchain. As for my advice, again, I know that P2SH^2 and MAST's are quite hard to deploy, which is why my advice to users who think they have a use-case for data-in-the-blockchain is to go ahead and do so now. They'll have a few years to show that their applications are in fact valuable, at which time a majority of hashing power may decide that implementing anti-data-in-chain techniques would be a mistake. Also, it increasingly looks like the scalability stuff I'm working on can be done transparently in a backwards compatible manner - actually implementing that stuff may prove to be less of a disruption than forcing all Bitcoin software to use new address types. |
|
|
|
So the transaction itself is without errors then, correct? And I just can't push it anywhere because everybody is trying to (rightly so) prevent me from clogging up the blockchain? The is the first manually created transaction I've made, so mostly I just want to know I've done it correctly. UPDATE: I was about to double spend it, but it looks like somebody did actually put it in a block. Did my tx broadcast even with the error -22 code or is it more likely somebody saw it here and broadcast it for me? UPDATE 2: Wow, ok, nevermind, I've answered my own question. That tx that got into a block is actually NOT the one I posted. It's an earlier version I made with a lower sequence number specifically so I could double-spend it easily if there were problems. But that version went through. So I know it must have been broadcast, because I hadn't posted that anywhere else. Ah, you're quite mistaken on a few levels. First of all nSequence was removed from Bitcoin literally years ago because it's insecure and makes Bitcoin vulnerable to DoS attacks. The wiki pages that mention it shouldn't, but unfortunately we've got a developer who's still hung up on the idea so... Secondly I think the -22 error code you saw just means your local bitcoind instance doesn't support OP_RETURN; have you upgraded it to either the 0.9 release candidate, or the latest from git? Looks like Eligius was who mined that tx, which makes me suspect Luke still hasn't actually disabled OP_RETURN transactions... Anyway, like I said, if you have a use for OP_RETURN, just make your application use it and have other data-encoding mechanisms as a fallback. The idea of "clogging up the blockchain" is nonsense. |
|
|
|
You don't need OP_RETURN to store data, particularly hashes. The idea being it was to encourage people to store data in the least harmful way possible in outputs that can be obviously pruned; like it or not putting data in the blockchain is useful so people will do it, and there's no good way to stop people from doing so. Of course, once data is prunable, it's no different than any other transaction in terms of impact on the system - you're still paying fees on the exact same basis as doing any other transaction. If you're planning on doing more than just playing around, what Mastercoin does to embed data is reasonably cheap and censorship resistant, and will become more so in the future: https://github.com/mastercoin-MSC/spec#appendix-a--storing-mastercoin-data-in-the-blockchainI'll add to that spec sooner or later with the P2SH scriptSig method of encoding; censoring that would require fairly invasive changes to the scripting language or blacklists. (fwiw I'm Mastercoin's Chief Scientist) |
|
|
|
It's been a while, and can't see anything on the Bitcoin Foundation's blog about it. Any idea when it's getting released? And is it 100% confirmed we'll be able to store up to 80 bytes of data in a transaction? That would be a god-send for us.
You already can store data in transactions; OP_RETURN just makes it easier to do that in ways that harm the Bitcoin network less. For instance see Mastercoin's "class B" encoding: https://github.com/mastercoin-MSC/spec#class-b-transactions-also-known-as-the-multisig-methodMy advice for new projects is to support multiple encoding methods, the same was Mastercoin did, so you aren't dependent on the Bitcoin devs. Incidentally there's no practical way to stop all those methods - even P2SH^2, itself a very invasive change to the ecosystem which is unlikely to happen, can't stop encoding data in P2SH scriptSigs without merkleized abstract syntax tree support and risky changes to the scripting language... and that in turn has the big risk that you make upgrades in the future, perhaps because a crypto algorithm has been weakened, much more difficult to implement. Of course, that's why I'm spending my time working on actually improving fundamental scalability rather than wasting time trying to tell people what to do with a trust-free decentralized system... |
|
|
|
What's the reason for 'zero' opcode? Bug in 'Checkmultisig'?
Yup. |
|
|
|
The devs are notoriously slow... They aren't even talking about it on the development mailing list today.
I guess that's what happens when you become rich... well, they'll soon know what it's like to be poor again...
Are you kidding? They've been discussing it on github: https://github.com/bitcoin/bitcoin/pull/3651ah, thanks. I'll retract my comment. I was looking in the wrong place. EDIT: sorry, looking at that pull request - it doesn't seem like it's going to fix the problem. It'll just patch the wallet to not recognize the unconfirmed trandsactions. Malleable transactions will still happen, we'll still be subject to the DDOS, and the exchanges will still need to make significant changes to their accounting software before re-opening withdrawals. Let me know if I got anything wrong there. You are. We're talking to those pools about how they can make use of that patch and others to make their accounting software work. |
|
|
|
|
Given the recent debacle about that 'StealthBit' trojan, please sign your code with your PGP key. Git now has per-commit signatures, which is what I recommend: git commit -S
I notice your PGP key, 0x7ad0a91c40bd0091, isn't in the web-of-trust, but signing the code is at least a good start.
|
|
|
|
|
Show Posts
