Re: [Bitcoin-development] Fee drop
On Tue, Feb 25, 2014 at 10:09:23AM -0800, Jeremy Spilman wrote: If I understand correctly, the risk here is this would open a historically large discrepancy between MIN_RELAY and the expected minimum fee to actually obtain block inclusion. I don't know if that's true, but I think that's what Peter is saying makes it different this time. That's exactly the problem. Of course every time we make a new transaction type standard we also run that risk, but at least it's a temporary situation and we can expect to get hashing power on-board fairly quickly. With such a low MIN_RELAY that's not true, and in an absolute sense, the funds required to DoS attack the network are fairly low. On Tue, 25 Feb 2014 08:55:58 -0800, Mike Hearn m...@plan99.net wrote: Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. It's annoying to do this by hand but by no means infeasible. Perhaps this is just another way to think of the floating fee problem. What does MIN_RELAY need to be so that my local resources stay within some reasonable limit (and 'reasonable' means different things to different nodes). We have an input gate on transactions entering mempool, we persist mempool, and I don't know the specifics but, I assume there's some expiration policy other than block inclusion to clear out a Tx from mempool. But are transactions prioritized in any way after they make it into mempool today? There's currently no expiration policy at all; that's the root of the DoS problem I was referring too. How closely should mempool selection align with the expected block inclusion? I think if they align perfectly in theory that means optimal mempool resource allocation. For example, a miner would push out cheaper transactions which they were previously hashing against to make room for higher fee transactions (bsaed on max block size or orphan rate projections), but do we do the same for mempool? E.g. - After hitting X number of transactions, the fee has to be larger than a transaction in mempool in order to get in, - That in turn that ejects a random transaction which paid less fees than the incoming Tx from mempool - We would have to consider how ejection would work with chains of unconfirmed transactions (cumulative average fee/kb?) but again in this case, you would want to 'do what miners would do' if you could Have you seen the mempool superblock design that keeps getting suggested? jgarzik has the most recent write-up here: https://github.com/bitcoin/bitcoin/issues/3723 I was working on a relatively ambitious version of it last summer that calculated the fee/KB for transactions, including depedencies, and then simply ordered the mempool with highest fee/KB first. The idea was you could then easily limit the total size of the mempool and drop transactions with the lowest fee/KB first. Transactions that paid less than the lowest fee/KB in a max-size mempool simply would not get relayed at all. Pity had to put it off for higher-priority work. What's interesting is how this makes zero-conf transactions even less safe: all you have to do to double-spend one (or more!) that pay X fee/KB is broadcast enough transactions paying X+e fee/KB to push out the unconfirmed tx from mepools around the network, then broadcast your double-spend. Obviously the economics of this are going to make attacks frequently profitable, especially if you can attack multiple targets at once. You can of course have schemes where you don't entirely drop transactions, saving, say, the inputs they spend and a transaction id, (so a rebroadcast can succeed) but that just reduces the effectiveness of the attack by a constant factor and makes it possible to get into complex situations where your funds are locked and unspendable. -- 'peter'[:-1]@petertodd.org 00011ffdfe2bfdf8f1f983bebfa160670b85afeebbd815fdf484 signature.asc Description: Digital signature -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP70 extension to allow for identity delegation
Now we're starting to see the first companies deploy BIP70, we're
encountering a need for identity delegation. This need was long foreseen by
the way: it's not in BIP70 because, well, we had to draw the line for v1
somewhere, and this is an issue that mostly affects payment processors. But
I figured I'd start a thread anyway because people keep asking me about it
:)
*Objective*
Identity delegation means that a payment request can be signed by someone
who is not holding the certified private key. The most obvious use case for
this is payment processors like BitPay and Coinbase who currently have to
sign payment requests as themselves. Other use cases might involve
untrusted sales agents who want to be able to accept payment as their
employer, but cannot be trusted with a long-term valuable secret, e.g.
because they take their phone into areas with high crime rates.
The lack of this is ok for v1 but not great, because:
1) It requires the name of the *actual* recipient to be put in the memo
field, otherwise you don't have the nice receipt-like properties. The memo
field is just plain text though, it doesn't have any exploitable structure.
2) It gives a confusing UI, the user thinks they're paying e.g. Overstock
but their wallet UI tells them they're paying Coinbase
3) Whilst these payment processors currently verify merchants so the
security risk is low, in future a lighter-weight model or competing sites
that allow open signups would give a weak security situation: a hacker who
compromised your computer could sign up for some popular payment processor
under a false identity (or no identity), and wait until you use your hacked
computer to make a payment to someone else using the same payment
processor. They could then do an identity swap of the real payment request
for one of their own, and your Trezor would still look the same. Avoiding
this is a major motivation for the entire system!
Also it just looks more professional if the name you see in the wallet UI
is correct.
*Proposed implementation*
We can fix this with a simple extension:
enum KeyType {
SECP256K1 = 1
}
message ExtensionCert {
required bytes signature = 1;
required bytes public_key = 2;
required KeyType key_type = 3;
required uint32 expiry_time = 4;
optional string memo = 5;
}
// modification
message X509Certificates {
repeated bytes certificate = 1;
repeated ExtensionCert extended_certs = 2;
}
message PaymentRequest {
// new field
optional bytes extended_signature = 6;
}
This allow us to define a so-called *extended certificate*, which is
conceptually the same as an X.509 certificate except simpler and Bitcoin
specific. To create one, you just format a ExtensionCert message with an
ECDSA public key from the payment processor (PP), set signature to an empty
array and then sign it using your SSL private key. Obviously the resulting
(most likely RSA) signature then goes into the signature field of the
ExtensionCert. The memo field could optionally indicate the purpose of this
cert, like Delegation to BitPay but I don't think it'd ever appear in the
UI, rather, it should be there for debugging purposes.
The new ExtensionCert can then be provided back to the PP who adds it to
the X509Certificates message. In the PaymentRequest, there are now
*two* signature
fields (this is for backwards compatibility). Because of how the mechanism
is designed they should not interfere with each other - old implementations
that don't understand the new extended_signature field will drop it during
reserialization to set signature to the empty array, and thus signature
should not cover that field. On the other hand, extended_signature would
cover signature. Thus, for full backwards compatibility, you would:
1) Sign the payment request using the PP's SSL cert, i.e. sign as
coinbase.com
2) Then sign again using the PP's delegated ECDSA key, i.e. sign as the
merchant
The finished protobuf would show up in old clients as signed by
coinbase.comand by new clients as signed by
overstock.com even though Overstock did not provide their SSL key to
coinbase.
If you have *only* an ExtensionCert and not any X.509 cert of your own,
then you cannot of course make backwards compatible signatures in this way,
and in that case you would miss out the signature field and set the
pki_type to a new value: x509+sha256+excert. Old wallets would see that
they don't understand this pki_type and treat the request as unverified.
For maximum security the merchant may choose to set very short expiry times
(like, a day) and then have a cron job that uploads a new ExtensionCert at
the end of each expiry period. This means in the case of PP compromise, the
system reseals very fast.
*Alternatives considered*
We could always use a new pki_type and not bother with the two signature
fields. However, this means old wallets will show payment requests as
untrusted during the transition period. Some signing is still better than
none, security-wise.
We could
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
On Thu, Feb 27, 2014 at 7:25 PM, Troy Benjegerdes ho...@hozed.org wrote: Either the transaction fees are sufficient to pay the cost for whatever random junk anyone wants to put there, or they are not, and if they are not, then I suggest you re-think the fee structure rather than trying to pre-regulate me putting 80 character pithy quotes in the blockhain. https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d In one way in particular, the transaction fees per kilobyte completely failed to account for the actual cost to the network. If Bitcoin had adopted a common-sense rule like this, I would have had no reason to join Litecoin development last year. This is one of the few economic design flaws that Satoshi overlooked in the original design. As much as I personally hate the idea of data storage in the blockchain, this at least discourages the creation of permanent UTXO. Warren Togami -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
On 2/28/14, Peter Todd p...@petertodd.org wrote: As usual, you don't need a hardfork. Anyway, one-sided trade is sufficient to get a functioning marketplace up and running and test out the many other issues with this stuff prior to forking anything. I'm totally FOR experimenting with this as it is and I'm happy that Alex/Killerstorm is working on regular colored coins. You can make the same argument against Bitcoin itself you know... A Bitmessage-like network would be trivial to front-run via a sybil attack. It's the fundemental problem with marketplaces - the data they're trying to publish has to be public. I don't see the Bitcoin analogy... Anyway, I still don't think the seller cares, if he sells at the price he was asking, what would he care about front running those parallel networks. I've seen many street markets without public information and they work just well. I don't think this will be a tragedy, because like we discussed on IRC, I don't think the primary goal of markets is price discovery, but trade itself. About historic data, the actual trades are always public, and some kind of archivers could collect and maintain old orders for historic bid and asks, etc. And again, how do you know that record is honest? Fact is without proof-of-publication you just don't. Well, the trades that appeared in the chain actually occurred. Buying to yourself at fake prices? Be careful, the miner could just separate the order and fill it himself. Or anyone paying a higher fee, for that matter. Again, you haven't addressed why the seller cares more about accurate historic market data than just his own fees and sell. You mean a reverse nLockTime that makes a transaction invalid after a certain amount of time - that's dangerous in a reorg unfortunately as it can make transactions permenantly invalid. Yes, I'm aware this is a concern for many people and that's why I bring it up when there's an useful use case (we have several important uses in freimarkets). Probably this belongs to another thread or just #wizards, but if I remember correctly, the last discussion we had about this, I think with you and gmaxwell, was more or less like this: -Valid transactions could get invalid with a regorg -Just like with any transaction if a double-spend appears, this just means that you would need to wait for expiry transactions to be somewhat buried to accept payments from it. -That introduces fungibility problems. -True, but doesn't seem a particularly difficult problem (I think we actually drafted some potential solutions, like introducing a maturity rule for expiry transactions) and the advantages outweigh that potential problem IMO. So in summary, I feel like before actually solving the problem we need to rise more awareness on how nice and necessary nExpiryTime would be. Anyway, sorry, I just wanted to point out another use, a deeper discussion about this belongs to another thread. -- Jorge Timón http://freico.in/ -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Transaction fees are a DoS mitigating cost to the person making the transaction, but they are generally not paid to the people who actually incur costs in validating the blockchain. Actual transaction processing costs are an externality that is completely unpaid for. When I add a 1Kb transaction to the blockchain, there is an attached fee which probabilistically goes to one of the miners. But every other full node on the network also receives this transaction, processes it, and adds it to local storage. From now until the heat death of the universe that 1Kb of data will be redundantly stored and transmitted to every single person who validates the block chain. None of these countless people are reimbursed for their storage, bandwidth, and processing costs. Not even a single satoshi. Yes, transaction fees are broken. But it is their very nature which is broken (sending coins to the miners, not the greater validator set), and no little tweak like the one Warren links to will fix this. But, in the absence of a reformed fee regime - which it is not clear is even possible - one could at least make the hand-wavey argument that people who validate the block chain receive benefit from it as a payment network. Therefore processing of the block chain is paid for by the utility it provides once fully synced. However even this weak argument does not extend to general data storage. If you want to put all of wikileaks or whatever in the block chain, then you are extracting a rent from every full node which is forced to process and store this data for eternity without compensation or derived utility. You are extorting users of the payment network into providing a storage service at no cost, because the alternative (losing bitcoin as a payment network) would cost them more. That is not ethical behavior. That is not behavior which responsible developers should allow in the reference client. Mark On 02/28/2014 06:42 AM, Warren Togami Jr. wrote: On Thu, Feb 27, 2014 at 7:25 PM, Troy Benjegerdes ho...@hozed.org mailto:ho...@hozed.org wrote: Either the transaction fees are sufficient to pay the cost for whatever random junk anyone wants to put there, or they are not, and if they are not, then I suggest you re-think the fee structure rather than trying to pre-regulate me putting 80 character pithy quotes in the blockhain. https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d In one way in particular, the transaction fees per kilobyte completely failed to account for the actual cost to the network. If Bitcoin had adopted a common-sense rule like this, I would have had no reason to join Litecoin development last year. This is one of the few economic design flaws that Satoshi overlooked in the original design. As much as I personally hate the idea of data storage in the blockchain, this at least discourages the creation of permanent UTXO. Warren Togami -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTEOKjAAoJEAdzVfsmodw4vGIQAJ9OQvHl1+dIaDelrf03lGIf kQsiuB4JG1rRghsZZiW4NixPbB/Bdm4+m4pep01eiVOPXa+/32AgWVzSYyyMVRYB oTu24ITgtCu5vkjiHyzSavFnqsi+zMxVpscUekA6l6Tkr3RBNnrIssMiazYc+Bkx fP2vZehmPHQtp09WkapZ3DMqbMzQ7qPTGlKd1V+9X4S5uUNTdfT6JkC0HIqUSdVQ PHjjbuulgkdz4b7A6C2dE5kwXVKF9YFHL3zEtObfWDCiyY8wf2XHYI6nVGLbyQeN nrYCsMH99lUy+zmnbccqSPKhe0p5IaBLauk75zcLxEfzxuKVTvVg2LCaCXQaworv vBoAURdrB2pCfK8dZ7mllVLLLcNk+iOG0NDZHYE9e884OBfeuaG/zNgmgOD8GC1H FaDkIpm79x/i3ti3h8vdZPeY0fWdI8yuD9aCQZtvONM9hXdd7Qb07eHqIk7tY/In 7h6zdq27GQUdWN37yslxtDENY2q3yQ39+fjMGQEKVIE6rNwDyjurMCNHAWJp0hZO 7S/rDe2W2tHGPYakscHQh1g/uMAEEb4mGGc5yrfWxyOn5eb9OZiZb8RVXlnDwwH9 qr8qwLJ1b0Uxo981lyEmnLZSpCpAZvDLpjmocqirycNZpvyPnJJbE809vS/koD3d OutJkMja4TBuqaMSdKEI =KbW/ -END PGP SIGNATURE- -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool.
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
On 02/28/2014 07:25 PM, Mark Friedenbach wrote: Transaction fees are a DoS mitigating cost to the person making the transaction, but they are generally not paid to the people who actually incur costs in validating the blockchain. Actual transaction processing costs are an externality that is completely unpaid for. What that means is the network layer is broken and needs to be fixed. Bitcoin is the blockchain, not the P2P network. If the existing network is not incentive compatible, then that's the root cause which should be addressed. There's no reason to enshrine the broken behavior and use it as a roadblock to stop progress. -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k 0x1B438BF4.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
On 28 February 2014 14:42, Warren Togami Jr. wtog...@gmail.com wrote: https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d In one way in particular, the transaction fees per kilobyte completely failed to account for the actual cost to the network. If Bitcoin had adopted a common-sense rule like this, I would have had no reason to join Litecoin development last year. This is one of the few economic design flaws that Satoshi overlooked in the original design. Is there any particular reason that patch would not make it into bitcoin if submitted? Drak -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Positive and negative feedback on certificate validation errors
We currently have subtle positive feedback of a signed payment request in the form of the green background. Unsigned requests simply show up without the green background, as well as requests which provide a certificate but have a missing or invalid signature. There's a open bug (#3628) and pull request (#3684) to provide negative feedback (yellow background) for a missing or invalid signature, but it seems like there's some debate on whether bitcoind should do that... If an attacker can avoid the negative feedback by just stripping the signature and setting pki_type to none, then arguably there's no security benefit by singling out badly signed payment requests from unsigned payment requests. So perhaps the root problem is that the positive feedback (green background) is not strong enough to make its absence highly conspicuous to the end user. As an aside, how could we go about implementing the equivalent of HTTP Strict Transport Security for payment protocol to prevent this trivial signature stripping attack? Is this a possible extension field merchants are interested in? -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Positive and negative feedback on certificate validation errors
On Sat, Mar 1, 2014 at 7:26 AM, Jeremy Spilman jer...@taplink.co wrote: There's a open bug (#3628) and pull request (#3684) to provide negative feedback (yellow background) for a missing or invalid signature, but it seems like there's some debate on whether bitcoind should do that... The consensus there is to treat invalid and unsigned payment requests the same (apart from debug error logging). After all, the cost to the attacker to remove the signature or corrupt it is exactly the same. I do recommend testing that pull request (#3684) to see if it improves payment request reporting, and provide testing reports or suggestions in the github comments. I've been very busy the last few weeks with integrating and testing other pre-0.9 changes so I have been unable to look at the visual side of payment request stuff much. We could use some help there. If an attacker can avoid the negative feedback by just stripping the signature and setting pki_type to none, then arguably there's no security benefit by singling out badly signed payment requests from unsigned payment requests. Exactly. So perhaps the root problem is that the positive feedback (green background) is not strong enough to make its absence highly conspicuous to the end user. Well, ideas to make the difference more conspicuous are welcome. The green background is just to make a basic distinction. If it involves any imagery or graphics we do need contributions (with the appropriate MIT license), no one of us is an artist. As an aside, how could we go about implementing the equivalent of HTTP Strict Transport Security for payment protocol to prevent this trivial signature stripping attack? Is this a possible extension field merchants are interested in? Such a thing would be interesting for a future BIP standard. I see one problem here: for an unsigned payment request there isn't really an origin. Browser URI handlers don't send the referrer either. This rules out adding a field to the Bitcoin URI 'requests from us must be signed from now on' (there's no us). The server that serves the payment requests *could* serve an HSTS-like header 'only accept signed payment requests from us from now on'. The client needs to remember this for this server. Then if someone has compromised that server (or hijacked DNS) to serve fake and unsigned payment requests, the client can block these. Neither scenario will help in the case in which the server serving the Bitcoin URIs is compromised. Wladimir -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Positive and negative feedback on certificate validation errors
On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir laa...@gmail.com wrote:Such a thing would be interesting for a future BIP standard. I see one problem here: for an unsigned payment request there isn't really an "origin". Browser URI handlers don't send the referrer either.Yeah, good point. If you have a cert, we have the CN from the cert, which becomes the string displayed as 'Pay To' and alternatively 'Merchant'.But if there's no cert then all you have is memo.So the best way to differentiate signed requests is by prominently displaying that Merchant string. Really the green part should just be the 'Pay To' line, the rest is content. If it showed a BLANK 'Pay To' that would make the lack of certificate highly apparent.-- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
