Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
On Thu, Nov 6, 2014 at 11:12 PM, Peter Todd wrote: > BIP62 does make life easier for wallet authors as they don't have to > deal with malleability - maybe! - Yes, I agree for most contract purposes CTLV is what you want to be using, instead of refund transactions beyond being more clearly correct, it shrinks the protocol state machine by one step. Though BIP62 also achieves the secondary goal of making required implementation behaviour more explicit (e.g. the parts enforced in all transactions), and that shouldn't be discounted. They're somewhat orthogonal, somwhat complementary things. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
On Thu, Nov 06, 2014 at 05:36:55PM -0600, Justus Ranvier wrote: > This explanation is completely incoherent. > > Because Bitcoin has a extra consensus requirements, requirements which > are really rare in engineering, the necessity of fixing bugs is even > greater. > > There are two general ways to fix bugs: either as part of a > controlled, planned, and managed process, or as a response to an > immediate disaster. > > The alternative to scheduling and planning the upgrades which are > necessary to fix the bugs in the protocol, where such fixes can be > written, tested, and documented at leisure, is to wait for some crisis > and slap on another bandaid when the network breaks again (like it did > March of last year). The protocol is what the protocol is; the bugs are when you don't match the protocol. > Who benefits from not fixing bugs in Bitcoin? We can bring up politics if you want. In the current model, the specification *is* the protocol, and the Bitcoin Core team is scared to death of changing anything; they've got very little real power. Soft-forks are the minimum-viable way of making changes to the protocol, and it's very clear how they get adopted: minerr consensus. They're also a fundemental way of changing the protocol that is impossible to prevent, so you might as well use it. Hard-forks require political consensus to achieve, and the way you create that political consensus is by creating committes, groups, associations... Foundations. Every last one of those things requires centralization and political power. You know, the smartest thing the Bitcoin Foundation could do if they wanted to cement their place in the Bitcoin ecosystem as a power broker would be to setup a program of periodic hard-forks, say every year or two, and then manage the committees that decide what goes into those hard-forks. That they haven't suggested that yet is a sign that they're either not evil, or they don't understand Bitcoin very well. I think programmers find this reality hard to accept, because they're mostly interested in writing code that'll get widely used. To them it's hard to accept that the Bitcoin protocol *is* a few thousand lines of C++ code, and they're not good enough to write their own implementation and make it match; if we replaced programmers with writers we might get the equally bizzare and pointless situation of people taking perfectly good RFCs and rewriting them in their own words. If you do care about keeping the politics of Bitcoin development free from centralized control you should do what I advised the Dark Wallet team to do a year ago: fork Bitcoin Core and change the non-consensus-critical code that implements policy. I've done this myself in a minor way with my replace-by-fee(1) version. Luke-Jr has also done this with his Eligius branch, a fork that something like 30% of the Bitcoin hashing power appear to run. (Discus Fish has been mining non-standard transactions(2) lately) Multiple *forks* of the Bitcoin Core reference client that are actually getting used by miners and other users ensures that no one group maintaining such a fork has the ability to change anything without strong consensus. Forking the codebase, rather than rewriting it, best ensures that your code actually implements the protocol properly, is safe to use for mining, and actually gets used. Rewriting Bitcoin Core is a fun project, but it's terrible politics. 1) https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.9.3 2) https://blockchain.info/tx/e24a4085c54a6362e615f8eab758c12d80e488b73757e6d2b8ab6bfc8be7007e -- 'peter'[:-1]@petertodd.org 08f2290924a6882928d4566f487f33cc57203a6535795201 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DS Deprecation Window
Added a section "Confidence to include tx1" and subsection "Deliberate delay attack" https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md I found that under concerted attack, if miner excludes any transaction first seen less than 30 seconds ago, or double-spent less than 30 seconds after first seen, he should expect 5 of 1 nodes to delay his block. Hal Finney remarked that this idea would need "careful analysis." More help is very welcome. https://bitcointalk.org/index.php?topic=3441.msg48789#msg48789 Cheers! On 10/28/2014 10:38 AM, Tom Harding wrote: > So, I think it will be possible to quantify and target the risk of > including tx1... > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/06/2014 05:26 PM, Peter Todd wrote:> For the same reason we don't do hard-forking upgrades of basically every > protocol on the planet on a regular basis, even when we don't have > consensus problems to worry about. > > Flag days are really rare in engineering, and for good reason. This explanation is completely incoherent. Because Bitcoin has a extra consensus requirements, requirements which are really rare in engineering, the necessity of fixing bugs is even greater. There are two general ways to fix bugs: either as part of a controlled, planned, and managed process, or as a response to an immediate disaster. The alternative to scheduling and planning the upgrades which are necessary to fix the bugs in the protocol, where such fixes can be written, tested, and documented at leisure, is to wait for some crisis and slap on another bandaid when the network breaks again (like it did March of last year). Who benefits from not fixing bugs in Bitcoin? - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJUXAYVAAoJEMP3uyY4RQ21YxMH/3O+vFK2jDXV5V8IIsJnU/u1 D4gYyVm89E0zmGTyLAUYCJGj0eg5tMyUUzu62hOECOeQuKdVi+mbkLi4TiF0sHIb 8k25MgqJgzH/021eoI2g2w1FrDlZut02LNX/V09+owd1yhp+SEXZ3/+HlqsZXhsv /u9u5OayzhGlzS6apQtrosl5P+KIquHqIbtwBtPOb2rvlL0miJ6sRcAH2JCXCBDT HMcswMtIGZbgqL/K7e/6vH7dUWdp0866RZXvt7aWGNUgvxHbGMs+zsnxp4nNslxM wqL71gTmtMnLcw0GtqmXPjcjo+adrPnqp45xc9lSt23PGjxxfR0FKYIPb2uZdq8= =9GOY -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
On Thu, Nov 06, 2014 at 04:48:54PM -0600, Justus Ranvier wrote: > Why not schedule protocol upgrades every two years for the foreseeable > future? For the same reason we don't do hard-forking upgrades of basically every protocol on the planet on a regular basis, even when we don't have consensus problems to worry about. Flag days are really rare in engineering, and for good reason. -- 'peter'[:-1]@petertodd.org 08f2290924a6882928d4566f487f33cc57203a6535795201 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
On Thu, Nov 06, 2014 at 11:11:52PM +0100, Jeff Garzik wrote: > IMO, CHECKLOCKTIMEVERIFY should be included in that list, too. > > RE soft fork vs. hard fork: It's about this time at Mike Hearn will > chime in, on the side of hard forks. Hard forks are in a sense much > cleaner, and permit solving problems not otherwise solvable with a > hard fork. However, hard forks clearly have risks, notably the Big > Risk akin to a US Constitutional Convention: once you open the door, > anything can happen, any rule no matter how "sacred" can be changed. I think people in this community often miss the serious political and legal ramifications of hard-forks. Being in the social position of being able to succesfully pull off hard-forks, particularly for new features, is clear evidence that you have de-facto control over the system. Regulators around the world appear to be going in directions that would make that control subject to regulation and licensing, e.g. the European Banking Association proposals, and initial Bitlicense proposals. Equally, look how hard-forks - known as flag days elsewhere - are generally considered to be dangerous and worth avoiding in other contexts due to simple engineering reasons. It's just easier to upgrade systems in backward compatible ways, especially when they incorporate features specifically to make that possible. (as does bitcoin!) > Soft forks are not without their own risks, e.g. reducing some things > to SPV levels of security. This is a misconception; you can't prevent soft-forks from happening, so you always have an SPV level of security by that standard. People put *way* too much trust in small numbers of confirmations... -- 'peter'[:-1]@petertodd.org 0094d543907eaf0f94f4ff5f4c760b3552d84ff811cd9053 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
On Thu, Nov 06, 2014 at 10:05:54PM +, Matt Corallo wrote: > Depends, without BIP62 a /lot/ of the even basic contracts that people > want to use today (or wanted to use 18 months ago) are unusable, in > fact, without BIP62, the atomic swaps suggested as important for > sidechains are not secure. While redoing Bitcoin in a hardfork is nice, > its a very long-term thing, so I'm not sure about making people wait for > a large hardfork just to use payment channels. BIP62 is a less-than-ideal way of making contracts secure against malleability as it relies on a "whack-a-mole" approach to security that is insecure if any flaw is missed. If you only wanted to make contracts secure, you'd either implement a new SignatureHash() that could leave out the prevout field in favor of hashing the previous input's CTxOut() structure, and/or implement the significantly more limited CHECKLOCKTIMEVERIFY. Equally BIP62 fails at making more complex types of contracts secure. For instance suppose I had a multi-step protocol that required more than two transactions: tx1: Alice -> (Alice, Bob) tx1_refund: (Alice, Bob) -> Alice tx2: (Alice, Bob) -> Charlie tx2_refund: (Alice, Bob) -> Bob tx1 can only be modified by Alice, so tx1_refund is secure. However the second stage, where the output of tx1 is spent by tx2, with a refund transaction giving the funds back to Bob, can't be made secure as BIP62 can't prevent Alice from changing her signature, getting tx2' mined instead, and making tx2_refund invalid. OTOH a new form of signature hash that was a signature on tx2.vout structure rather than it's txid would be secure, as tx2_refund would be valid regardless of tx2's actual txid. Obviously there are good reasons to not use such signature hashes in the general case, as they imply you can't reuse scriptPubKeys securely, but that's a minor problem for purpose-built contract protocols. It's certainly a much more minor problem then the huge number of holes possible with BIP62. BIP62 does make life easier for wallet authors as they don't have to deal with malleability - maybe! - but for contracts it's a bad design. > Also, I echo the difficulty of writing consensus-compatible code and > highly suggest anyone with money behind an implementation that is doing > script verification in code that isnt Bitcoin Core rethink that decision. FWIW I've done due-dilligence reviews for investors on projects and companies that have re-implemented Bitcoin Core consensus-critical code, and every time my review lists doing so as a major red flag. -- 'peter'[:-1]@petertodd.org 166801ed3959dde6b7d979735c290e7c4271ae3cf75ced63 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
On 11/06/2014 04:11 PM, Jeff Garzik wrote: > RE soft fork vs. hard fork: It's about this time at Mike Hearn will > chime in, on the side of hard forks. Hard forks are in a sense much > cleaner, and permit solving problems not otherwise solvable with a > hard fork. However, hard forks clearly have risks, notably the Big > Risk akin to a US Constitutional Convention: once you open the door, > anything can happen, any rule no matter how "sacred" can be changed. Yes, there are risks, but those risks could be managed with appropriate effort. Major players could publicly commit to a set of ground rules vis a vis what categories of changes are and are not acceptable. Maybe at some point there could even be something that resembles project management for the Bitcoin protocol. Why not schedule protocol upgrades every two years for the foreseeable future? Spend one year achieving broad consensus regarding what changes to make in the next upgrade, then spend one year in feature freeze (all future proposals postponed for the next cycle) then execute the upgrade. The top priority should be fixing bugs that make specifying and re-implementing the protocol nearly impossible. Those kinds of changes should have little difficulty achieving near-unanimous consensus. There shouldn't be any problems separating obviously-needed changes from the ones that let third parties blacklist coins, or a majority of miners vote to confiscate block rewards from minority, tamper with the issuance schedule, etc. -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k 0x38450DB5.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
IMO, CHECKLOCKTIMEVERIFY should be included in that list, too. RE soft fork vs. hard fork: It's about this time at Mike Hearn will chime in, on the side of hard forks. Hard forks are in a sense much cleaner, and permit solving problems not otherwise solvable with a hard fork. However, hard forks clearly have risks, notably the Big Risk akin to a US Constitutional Convention: once you open the door, anything can happen, any rule no matter how "sacred" can be changed. Soft forks are not without their own risks, e.g. reducing some things to SPV levels of security. Leaning towards soft fork, but it is a good discussion to have. A poorly implemented soft fork may potentially require a hard fork to fix rollout bugs. On Thu, Nov 6, 2014 at 11:05 PM, Matt Corallo wrote: > Depends, without BIP62 a /lot/ of the even basic contracts that people > want to use today (or wanted to use 18 months ago) are unusable, in > fact, without BIP62, the atomic swaps suggested as important for > sidechains are not secure. While redoing Bitcoin in a hardfork is nice, > its a very long-term thing, so I'm not sure about making people wait for > a large hardfork just to use payment channels. > > Also, I echo the difficulty of writing consensus-compatible code and > highly suggest anyone with money behind an implementation that is doing > script verification in code that isnt Bitcoin Core rethink that decision. > > Matt > > On 11/06/14 21:58, Tamas Blummer wrote: >> Thanks Peter, >> >> Having tried to write a bug-for-bug compatible code with Satoshi, I can only >> second that it is rather close to impossible. >> >> The aim of BIP62 is noble, still it does not feel right for me to increase >> the complexity of the code with e.g. soft-fork-ready versioning. >> Freezing the consensus code, studying its bugs appears more appropriate to >> me. What we learn could define a hard fork or a better >> chain we migrate to as discussed by blockstream. >> >> Tamas Blummer > > -- > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Depends, without BIP62 a /lot/ of the even basic contracts that people want to use today (or wanted to use 18 months ago) are unusable, in fact, without BIP62, the atomic swaps suggested as important for sidechains are not secure. While redoing Bitcoin in a hardfork is nice, its a very long-term thing, so I'm not sure about making people wait for a large hardfork just to use payment channels. Also, I echo the difficulty of writing consensus-compatible code and highly suggest anyone with money behind an implementation that is doing script verification in code that isnt Bitcoin Core rethink that decision. Matt On 11/06/14 21:58, Tamas Blummer wrote: > Thanks Peter, > > Having tried to write a bug-for-bug compatible code with Satoshi, I can only > second that it is rather close to impossible. > > The aim of BIP62 is noble, still it does not feel right for me to increase > the complexity of the code with e.g. soft-fork-ready versioning. > Freezing the consensus code, studying its bugs appears more appropriate to > me. What we learn could define a hard fork or a better > chain we migrate to as discussed by blockstream. > > Tamas Blummer -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Thanks Peter, Having tried to write a bug-for-bug compatible code with Satoshi, I can only second that it is rather close to impossible. The aim of BIP62 is noble, still it does not feel right for me to increase the complexity of the code with e.g. soft-fork-ready versioning. Freezing the consensus code, studying its bugs appears more appropriate to me. What we learn could define a hard fork or a better chain we migrate to as discussed by blockstream. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Running a full node
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 If you are considering running a full node (or think you are running one), you should read the comments here: https://www.reddit.com/r/Bitcoin/comments/1scd4z/im_running_a_full_node_and_so_should_you/cdw38ve Thomas Zander wrote: > On Thursday 6. November 2014 10.51.38 Francis GASCHET wrote: >> Dear all, >> >> I'm currently discovering the Bitcoin's universe. I installed >> bitcoind on my PC and I'm currently testing different things on >> testnet. I just read an article saying that the risk for Bitcoin >> in the future is the decreasing number of full nodes, with >> appropriate resources. There are only few of them in France ! >> >> My company operates a dual homed Internet access and has some >> capacity to host an HA server in a secured environment. So I'm >> thinking about setting up a full node. But I'd like to know what >> storage, RAM and bandwidth resources are needed. I guess that >> the problem is not the CPU. > > There is a stats script running on this node; > > http://213.165.91.169/ > > more peoples opinions; > https://bitcointalk.org/index.php?topic=760094.0 > - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJUW+pWAAoJEGxwq/inSG8CMOEH/jLElWVYTepe0kwnHiguvM2T Y16fSfLuptdpHU0+2du0U7zO14UvhL7mA2cQxDPxvC72hqRfMld3x5+Pz1mM8aik Xgot1XrFEo2fQn4CRyaEdwIj0SG5+dcnNSPWJcAf/aLSmw6BFaFgVbG9Qenzrvfn wgJBaqP0RWTox6ctsDZAHbVTo1+t4/ERwX1YMcQJkAKLN4IZmYqFIaRV6TRU5jSy af1Smnn+2GmryYlAH+DDJ/4C7BxfCCMnWuItjne7AxMUI/4aDJO1lv/s5lkQYCJU 2dYFV5ZYyS+Ff9895eI9GDu2N+b/QuiiKWsX8leshmCB8/XrPjHqjfP0eABnBKM= =Augd -END PGP SIGNATURE- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug
Recently wrote the following for a friend and thought others might learn
from it.
> Nope, never heard that term. By "bug-for-bug" compatibility, do you mean
> that, for each version which has a bug, each bug must behave in the *same*
> buggy way?
Exactly. tl;dr: if you accept a block as valid due to a bug that others reject,
you're forked and the world ends.
Long answer... well you reminded me I've never actually written up a good
example for others, and a few people have asked me for one. A great example of
this is the SIGHASH_SINGLE bug in the SignatureHash() function:
uint256 SignatureHash(CScript scriptCode, const CTransaction& txTo,
unsigned int nIn, int nHashType)
{
else if ((nHashType & 0x1f) == SIGHASH_SINGLE)
{
// Only lock-in the txout payee at same index as txin
unsigned int nOut = nIn;
if (nOut >= txTmp.vout.size())
{
printf("ERROR: SignatureHash() : nOut=%d out of range\n", nOut);
return 1;
}
}
// Serialize and hash
CHashWriter ss(SER_GETHASH, 0);
ss << txTmp << nHashType;
return ss.GetHash();
}
So that error condition results in SignatureHash() returning 1 rather than the
actual hash. But the consensus-critical code that implements the CHECKSIG
operators doesn't check for that condition! Thus as long as you use the
SIGHASH_SINGLE hashtype and the txin index is >= the number of txouts any valid
signature for the hash of the number 1 is considered valid!
When I found this bug¹ I used it to fork bitcoin-ruby, among others.
(I'm not the first; I found it independently after Matt Corallo) Those
alt-implementations handled this edge-case as an exception, which in
turn caused the script to fail. Thus they'd reject blocks containing
transactions using such scripts, and be forked off the network.
You can also use this bug for something even more subtle. So the
CHECKSIG* opcode evaluation does this:
// Drop the signature, since there's no way for a signature to sign itself
scriptCode.FindAndDelete(CScript(vchSig));
and CHECKMULTISIG* opcode:
// Drop the signatures, since there's no way for a signature to sign itself
for (int k = 0; k < nSigsCount; k++)
{
valtype& vchSig = stacktop(-isig-k);
scriptCode.FindAndDelete(CScript(vchSig));
}
We used to think that code could never be triggered by a scriptPubKey or
redeemScript, basically because there was no way to get a signature into a
transaction in the right place without the signature depending on the txid of
the transaction it was to be included in. (long story) But SIGHASH_SINGLE makes
that a non-issue, as you can now calculate the signature that signs '1' ahead
of time! In a CHECKMULTISIG that signature is valid, so is included in the list
of signatures being dropped, and thus the other signatures must take that
removal into account or they're invalid. Again, you've got a fork.
However this isn't the end of it! So the way FindAndDelete() works is as
follows:
int CScript::FindAndDelete(const CScript& b)
{
int nFound = 0;
if (b.empty())
return nFound;
iterator pc = begin();
opcodetype opcode;
do
{
while (end() - pc >= (long)b.size() && memcmp(&pc[0], &b[0],
b.size()) == 0)
{
pc = erase(pc, pc + b.size());
++nFound;
}
}
while (GetOp(pc, opcode));
return nFound;
}
So that's pretty ugly, but basically what's happening is the loop iterates
though all the opcodes in the script. Every opcode is compared at the *byte*
level to the bytes in the argument. If they match those bytes are removed from
the script and iteration continues. The resulting script, with chunks sliced
out of it at the byte level, is what gets hashed as part of the signature
checking algorithm.
As FindAndDelete() is always called with CScript(vchSig) the signature
being found and deleted is reserialized. Serialization of bytes isn't
unique; there are multiple valid encodings for PUSHDATA operations. The
way CScript() is called the most compact encoding is used, however this
means that if the script being hashed used a different encoding those
bytes are *not* removed and thus the signature is different.
Again, if you don't get every last one of those details exactly right, you'll
get forked.
...and I'm still not done! So when you call CScript(vchSig) the relevant code
is the following:
class CScript : public std::vector
{
explicit CScript(const CScriptNum& b) { operator<<(b); }
CScript& operator<<(const std::vector& b)
{
if (b.size() < OP_PUSHDATA1)
{
insert(end(), (unsigned char)b.size());
}
else if (b.size() <= 0xff)
{
insert(end(), OP_PUSHDATA1);
insert(end(),
[Bitcoin-development] Nakapay - Proposal for payment method using client generated paycodes and federated paycode servers
I sent this yesterday but it is not showing in the archives, so I'm not sure if I did it correctly. I sent it prior to subscribing, so perhaps that mucked it up. nakapay.com I have developed a system whereby a person requesting Bitcoin can make a specific request (amount, address, timeframe, etc...) by only communicating a 6 character paycode to a payer. The system does not require that users sign up for the service; it is open to all. Users may submit information by POST via my API for which I have documentation on the website above. It is my intention to convince wallet developers, merchants, exchanges, and payment processors to integrate my system into their products. Common objections are a lack of use cases and a lack of security. I'd like to explore possible use cases and discuss security with this mailing list. When talking to wallet developers, I've gotten the impression that there is a chicken and egg problem with my product. If no one uses it, they won't develop for it, and if they don't develop for it ... on and on. There are possible monetary incentives for development as there is a possible revenue stream for paycode server operators. I've not used a mailing list like the before, so I'm not sure if this submission is getting where it needs to go. Thank you all for your time and continued efforts to improve Bitcoin. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT
On Thu, 6 Nov 2014 05:45:09 -0500 Peter Todd wrote: > On Thu, Nov 06, 2014 at 05:38:20AM -0500, Peter Todd wrote: > > So right now git head will accept the following invalid transaction > > into the mempool: > > > > 010001140de229e08fda25cbc16ded2618cdacce49fcb18c0b6ccdace00040909adae49000493046022100f7828d81c849c5448ba5ba4ef55df6b4d0ba3ae3f1a59cff3291880c2c8e524f022100d2f5bc9dc2f0674eded31023cb47e61a596e10f8f1ddd44cf92d290c9db577c70144410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455ac9101102717a914e661a2229cc824329c9409f49d99cb5ac350c92887 > > > > which spends the redeemScript: > > > > 0778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455 > > CHECKSIG NOT > > ...and while we're at it, bitcoin-ruby's forked yet again... > It is? How do you reckon? The webbtc node just received a block: http://webbtc.com/block/006370724f73798f4c00c8da97f675c4dcf4605e9882913c You mean it would be forked off if this change was released? pgpDzb0nNBhAW.pgp Description: OpenPGP digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Running a full node
On Thursday 6. November 2014 10.51.38 Francis GASCHET wrote: > Dear all, > > I'm currently discovering the Bitcoin's universe. > I installed bitcoind on my PC and I'm currently testing different things > on testnet. I just read an article saying that the risk for Bitcoin in the > future is the decreasing number of full nodes, with appropriate resources. > There are only few of them in France ! > > My company operates a dual homed Internet access and has some capacity to > host an HA server in a secured environment. So I'm thinking about setting > up a full node. But I'd like to know what storage, RAM and bandwidth > resources are needed. I guess that the problem is not the CPU. There is a stats script running on this node; http://213.165.91.169/ more peoples opinions; https://bitcointalk.org/index.php?topic=760094.0 -- Thomas Zander -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT
On Thu, Nov 06, 2014 at 02:47:29AM -0800, Pieter Wuille wrote:
> On Thu, Nov 6, 2014 at 2:38 AM, Peter Todd wrote:
> > However the implementation of the STRICTENC flag simply makes pubkey
> > formats it doesn't recognize act as through the signature was invalid,
> > rather than failing the transaction. Similar to the invalid due to too
> > many sigops DoS attack I found before, this lets you fill up the mempool
> > with garbage transactions that will never be mined. OTOH I don't see any
> > way to exploit this in a v0.9.x IsStandard() transaction, so we haven't
> > shipped code that actually has this vulnerability. (dunno about
> > alt-implementations)
>
> Yeah, there's even a comment in script/interpreter.h currently about
> how STRICTENC is not softfork safe.
Indeed.
I actually was thinking about SCRIPT_VERIFY_MINIMALDATA, CScript(), and
FindAndDelete() Specifically that if you were to change CScript() to
convert single-character PUSHDATA's to OP_ you'd be making a
consensus-critical change due to how FindAndDelete() is called with a a
CScript() signature. You didn't make that mistake, and I couldn't find a
way to exploit it anyway, but it reminded me of this STRICTENC stuff.
> I didn't realize that this would
> lead to the mempool accepting invalid transactions (I thought there
> was a second validity check with the actual consensus rules; if not,
> maybe we need to add that).
It should be enough to just duplicate the CheckInputs() call in
the AcceptToMemoryPool() function:
if (!CheckInputs(tx, state, view, true, STANDARD_SCRIPT_VERIFY_FLAGS, true))
{
return error("AcceptToMemoryPool: : ConnectInputs failed %s",
hash.ToString());
}
if (!CheckInputs(tx, state, view, true, MANDATORY_SCRIPT_VERIFY_FLAGS,
true))
{
return error("AcceptToMemoryPool: : BUG FOUND Standard verify flags
passed yet mandatory flags failed. %s", hash.ToString());
}
> > I suggest we either change STRICTENC to simply fail unrecognized pubkeys
> > immediately - similar to how non-standard signatures are treated - or
> > fail the script if the pubkey is non-standard and signature verification
> > succeeds.
>
> Sounds good to me, I disliked those semantics too.
Ok, then given we have to support hybrid encoding for awhile longer
anyway - I noticed your secp256k1 library supports it - lets do the
latter as a "least invasive" measure. I can't think of any case where
that'd be triggered other than delibrately. Doing that should make
STRICTENC a soft-fork-safe change, and we can decide at a later date if
we want to get rid of hybrid-encoded pubkeys in a further tightening of
the rules.
--
'peter'[:-1]@petertodd.org
19b3c625f667bd0b93011c0a37950545a6a8fccf0b08ae73
signature.asc
Description: Digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT
On Thu, Nov 6, 2014 at 2:47 AM, Pieter Wuille wrote: >> I suggest we either change STRICTENC to simply fail unrecognized pubkeys >> immediately - similar to how non-standard signatures are treated - or >> fail the script if the pubkey is non-standard and signature verification >> succeeds. > > Sounds good to me, I disliked those semantics too. Of course: do we apply this rule to all pubkeys passed to CHECKMULTISIG (my preference...), or just the ones that are otherwise checked? This will likely make existing outputs hard to spend as well (I don't have numbers), are we okay with that? We probably can't make this a consensus rule, as it may make existing P2SH outputs/addresses unspendable. -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT
On Thu, Nov 6, 2014 at 2:38 AM, Peter Todd wrote: > However the implementation of the STRICTENC flag simply makes pubkey > formats it doesn't recognize act as through the signature was invalid, > rather than failing the transaction. Similar to the invalid due to too > many sigops DoS attack I found before, this lets you fill up the mempool > with garbage transactions that will never be mined. OTOH I don't see any > way to exploit this in a v0.9.x IsStandard() transaction, so we haven't > shipped code that actually has this vulnerability. (dunno about > alt-implementations) Yeah, there's even a comment in script/interpreter.h currently about how STRICTENC is not softfork safe. I didn't realize that this would lead to the mempool accepting invalid transactions (I thought there was a second validity check with the actual consensus rules; if not, maybe we need to add that). > I suggest we either change STRICTENC to simply fail unrecognized pubkeys > immediately - similar to how non-standard signatures are treated - or > fail the script if the pubkey is non-standard and signature verification > succeeds. Sounds good to me, I disliked those semantics too. -- Pieter -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT
On Thu, Nov 06, 2014 at 05:38:20AM -0500, Peter Todd wrote: > So right now git head will accept the following invalid transaction into > the mempool: > > 010001140de229e08fda25cbc16ded2618cdacce49fcb18c0b6ccdace00040909adae49000493046022100f7828d81c849c5448ba5ba4ef55df6b4d0ba3ae3f1a59cff3291880c2c8e524f022100d2f5bc9dc2f0674eded31023cb47e61a596e10f8f1ddd44cf92d290c9db577c70144410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455ac9101102717a914e661a2229cc824329c9409f49d99cb5ac350c92887 > > which spends the redeemScript: > > 0778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455 > CHECKSIG NOT ...and while we're at it, bitcoin-ruby's forked yet again... -- 'peter'[:-1]@petertodd.org 152dc55f27338b58325f0432d2dc6edb90c8d449d9959583 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT
So right now git head will accept the following invalid transaction into the mempool: 010001140de229e08fda25cbc16ded2618cdacce49fcb18c0b6ccdace00040909adae49000493046022100f7828d81c849c5448ba5ba4ef55df6b4d0ba3ae3f1a59cff3291880c2c8e524f022100d2f5bc9dc2f0674eded31023cb47e61a596e10f8f1ddd44cf92d290c9db577c70144410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455ac9101102717a914e661a2229cc824329c9409f49d99cb5ac350c92887 which spends the redeemScript: 0778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455 CHECKSIG NOT That pubkey is valid and accepted by OpenSSL as it's obscure "hybrid" format. The transaction is invalid because the signature is correct, causing CHECKSIG to return 1, which is inverted to 0 by the NOT. However the implementation of the STRICTENC flag simply makes pubkey formats it doesn't recognize act as through the signature was invalid, rather than failing the transaction. Similar to the invalid due to too many sigops DoS attack I found before, this lets you fill up the mempool with garbage transactions that will never be mined. OTOH I don't see any way to exploit this in a v0.9.x IsStandard() transaction, so we haven't shipped code that actually has this vulnerability. (dunno about alt-implementations) I suggest we either change STRICTENC to simply fail unrecognized pubkeys immediately - similar to how non-standard signatures are treated - or fail the script if the pubkey is non-standard and signature verification succeeds. Thoughts? -- 'peter'[:-1]@petertodd.org 152dc55f27338b58325f0432d2dc6edb90c8d449d9959583 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Running a full node
Dear all, I'm currently discovering the Bitcoin's universe. I installed bitcoind on my PC and I'm currently testing different things on testnet. I just read an article saying that the risk for Bitcoin in the future is the decreasing number of full nodes, with appropriate resources. There are only few of them in France ! My company operates a dual homed Internet access and has some capacity to host an HA server in a secured environment. So I'm thinking about setting up a full node. But I'd like to know what storage, RAM and bandwidth resources are needed. I guess that the problem is not the CPU. Thanks in advance for details. -- -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
