I'm curious to know how thoroughly these proposals have been tested. That might go a long way toward swaying opinion. I would imagine having a public alt-coin for the sole purpose of implementing one proposal or the other and seeing how easy it is to break could be a great proving ground. While practical testing is valuable, it should have no bearing on which BIP is accepted. These BIPs are protocol changes, and providing a stable implementation is the duty of the client, not the protocol. That being said, I'm confident that my bitcoind BIP 17 backports are more likely to hold up to testing, provided the signature check is sane (signing the relevant parts of the transaction), which would actually be a bug in the existing protocol if it weren't. I'll see if makomk is up to this. His "coiledcoin" post implied he might be. |
|
|
|
With reasonable justification but with little regard for propriety or the long-term consequences, Luke-Jr objects to Gavin's scheme's violation of the script and uses his considerable technical and social capital to engineer the scheme's failure. This brings us up-to-date. You forgot to mention "engineering its failure" includes "engineering a better, sane proposal"... BIP 17 |
|
|
|
But surely P2SH will be delayed, again, because of you. Nice Work, Luke. The only unnecessary delay at this point is from people trying to push BIP 16 through when we have a sane alternative. If everyone was focussed on BIP 17, we'd be there in no time.  |
|
|
|
Don't troll. Eligius is pro-P2SH (BIP 17).
BIP17 is OP_CHV, not OP_P2SH - as you well know. Be straight: Eligius is pro-BIP17 and therefore anti-BIP16, am I correct? There is no OP_P2SH. BIP 12, 16, and 17 are all competing standards for P2SH. BIP 17 is the most sane, and BIP 16 the least. |
|
|
|
Leave Eligius!
It's against /P2SH/
Don't troll. Eligius is pro-P2SH (BIP 17). |
|
|
|
Me too. Too many votes for BIP16 |
|
|
|
Is it possible to also somehow close the hole about adding stuff into transaction before scriptSig by malicious nodes thus changing txID if modified transaction gets mined into block first?
Is it possible to address this in the future if not within BIP16? This can be fixed with or without P2SH of any kind. |
|
|
|
how about this:
sig1 OP_0 sig1 sig2 SEPARATOR 2 pub1 pub2 2 checkmultisig pub1
hash <hash(pub1)> compare checksig <hash(x)> OP_CHECKHASHVERIFY OP_DROP
x is all the mess from the separator up to the hash(x)
the pub will be twice as long but at a const. length (the complex script can be as long is it needs)
an old client will always verify at least the first sig Could use OP_DUP and such instead of the sig twice... but not too bad of an idea, actually! Addresses would end up a little long, but maybe not entirely unmanagable: 8TAwKxdJjw3tjdWJFhLg3PPnhaYFic1rHzDMTqmZukt1d2y8yFwEhAJndKcBM (length 61) This is based on 1 byte version (= 5), 20 bytes "script hash", 20 bytes "script hash" XOR "first signature hash" (so you can't change one without changing the other...), and then the usual 4 bytes checksum. |
|
|
|
I just don't like traditional pools and think people should consider what they are giving up when joining them. I did. That's why I started my own pool.  |
|
|
|
However, that is significantly better than BIP 17 where anyone can try redeeming it the second the BIP 17 transaction appears on the network. Not considering both BIPs require a supermajority hashpower of support to become active. |
|
|
|
I find it interesting that major changes were implemented to the client/protocol that helped pools before we started considering changes that would help the common bitcoin user. That is probably something that is endemic of our society. Helping the big interests in a society first makes it more difficult to implement changes for the betterment of all stakeholders.
To what are you referring? Specifically the ability to reward the generated coins in a new block to multiple addresses, thus making it easier for many new pool operators to payout to their miners. I recall that being a significant boost to the pool op community. Except that still hasn't been merged, though it should have been by now considering it has been well-tested for over 8 months and has zero effect on anyone who doesn't want to use it... There are also other mining-related improvements that should be, but also haven't been merged, which are needed to solo mine too (all bitcoind releases so far cannot handle the load required to solo mine). I'd like it if I (or someone else qualified) were allowed to maintain solo mining, at least until p2pool matures enough to be a viable replacement for solo mining, but the developers with push access seem content to let it stagnate until finally removing 'getwork' entirely in the future. But this is really getting off-topic IMO... |
|
|
|
Well I have scanned this system with Security Essentials, MRT, System Sweeper and Windows Defender Offline.
So I don't think it has a virus.
But now after several reboots I can again run the client. Doesn't exactly give me a warm fuzzy feeling. Perhaps open an issue on GitHub; maybe someone else knows how to debug Windows stuff. By the way, why is it now called Bitcoin-qt? The old client (aka wxBitcoin) was replaced with Bitcoin-Qt, which is a complete rewrite of the GUI. |
|
|
|
I noticed that Eligius doesn't ever have a negative buffer, wouldn't the SMPPS algo apply here? I presume Ars is showing "total issued extra credit" as its "negative buffer". Eligius has issued extra credit before, especially in the recent past few weeks, though we've mostly remained on the buffer side of the equation. |
|
|
|
I'm saying that BIP17 has no chances not because of me, but because I seriously doubt that it will be supported by anyone besides Eligius. I'm not the only one who concedes BIP 17 is better than BIP 16, and certainly better than nothing. Hopefully the pressure to rush BIP 16 will lighten up after it fails to meet its voting deadline, and people who just want P2SH rushed in will realize BIP 17 is not delaying things. Your hash rate is going down only in the past few days as people switch. I'm pretty sure Tycho is aware that his hashrate has been dropping for quite some time before BIP 16 already. There's no reason to think people are switching over this issue in particular.
Gavin, I would appreciate it if you would stop emailing other pool operators in secret to try to convince them to support BIP 16 (or at least stop with the FUD I've been hearing). Is there a reason these emails can't be posted openly? |
|
|
|
is there already an implementation of both BIPs? Yes, BIP 16 is in mainline git master, and BIP 17 has implementations for 0.3.19 onward. BIP 17 could gain the same robustness by the following (in python-like pseudocode): MetaEvaluate(scriptSig + OP_CODESEPARATOR + scriptPubKey)
Where MetaEvaluate is a function that: def MetaEvaluate(code):
pieces = code_split(code, OP_CODESEPARATOR)
stack = emptyStack
foreach piece in pieces:
stack = Evaluate(piece,stack)
I'm not going to write pseudocode for code_split but the first argument is the code to be split and the second is the instruction by which to separate it. I'm not sure if it makes sense to be able to split at any instruction but OP_CODESEPARATOR though. code_split does need to understand not to split in the middle of data though, so pure split won't work. Interesting, but it seems more likely to break something subtle to me, at least in regard to backward compatibility. But perhaps this option should be explored more if we have the time. |
|
|
|
If we are so worried about the size of the blockchain, it appears to me that BIP_17 is not the way to go because of increased amounts of data being stored in the chain. BIP 17 transactions use less data than BIP 16. In the current setup, scriptPubKey is the code, and scriptSig is the data. If BIP17 isn't executing code by virtue of reclassifying scriptSig into "code", then none of the others are either. Except scriptSig is not and has never been mere data, it is code. |
|
|
|
BTW, why is the address of BIP17 longer than BIP16? BIP17 and BIP16 both use BIP13 addresses... |
|
|
|
What am i missing here? If the old clients won't verify it, they will reject the block containing it entirely, no matter how many other nodes say it's legit. |
|
|
|
But i do not feel that bip17 is mature enough since it introduces new security risks.
So i think something like bip17 should be implemented, but in a way that cannot be exploited/misenterpreted by older clients even if BIPXX has less than 50% support. BIP 17 does not introduce any new security risks that aren't also risks with BIP 16. it does. if you send a new transaction before 50% of the hash power is updated it will be redeemable by anyone with bip16, you will at least need to know the script - its not much, but its not nothing either. And to redeem it, you have to make the script known even before your redemption gets confirmed. So any rogue miner/relayer can easily swipe it the moment you try to spend. |
|
|
|
But i do not feel that bip17 is mature enough since it introduces new security risks.
So i think something like bip17 should be implemented, but in a way that cannot be exploited/misenterpreted by older clients even if BIPXX has less than 50% support. BIP 17 does not introduce any new security risks that aren't also risks with BIP 16. |
|
|
|
|
Show Posts
