Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
First of all, sorry for the delayed answer. On 2/10/14, Peter Todd p...@petertodd.org wrote: Got this: [...] Thank you, I knew this wasn't new for us but I doubted we had written it anywhere. As said in those mails, being only able to offer AAA for BTC and not BTC for AAA nor AAA for BBB is enough of a limitation to justify a hardfork IMO. On 2/17/14, Troy Benjegerdes ho...@hozed.org wrote: Is there a simple way to do cross-chain trades that doesn't need a third chain to somehow facilitate things? These are the two methods I know for cross-chain trading (no third chain needed in any of them): https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains https://bitcointalk.org/index.php?topic=321228 On 2/14/14, Peter Todd p...@petertodd.org wrote: You're assuming the seller cares about fairness - why should they? They offered a price for an asset and someone bought it; exactly which buyer willing to buy at that price was able to complete the trade is irrelevant to them. What they do care about is being sure that at whatever given price they offered 100% of the buyers willing to buy at that price actually see the offer in a reasonable amount of time - at the best price the seller will get there will be only a single buyer after all so you need that solid proof that said buyer was actually able to get the offer. In fact, I don't think the seller will care enough about this to pay the proof of publication fee either. Assuming sellers can either broadcast the order on a bitmessage-like network or use your proof of publication scheme, the later will be always be more expensive. So my prediction is that most people will just use the simplest, fastest and cheapest method, but I guess only time can tell. 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. As an aside, nLockTime would be nice not to always have to double-spend the inputs of an order to cancel it. -- 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] Decentralized digital asset exchange with honest pricing and market depth
On Fri, Feb 28, 2014 at 12:48:33AM +0100, Jorge Timón wrote: First of all, sorry for the delayed answer. On 2/10/14, Peter Todd p...@petertodd.org wrote: Got this: [...] Thank you, I knew this wasn't new for us but I doubted we had written it anywhere. As said in those mails, being only able to offer AAA for BTC and not BTC for AAA nor AAA for BBB is enough of a limitation to justify a hardfork IMO. 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. On 2/14/14, Peter Todd p...@petertodd.org wrote: You're assuming the seller cares about fairness - why should they? They offered a price for an asset and someone bought it; exactly which buyer willing to buy at that price was able to complete the trade is irrelevant to them. What they do care about is being sure that at whatever given price they offered 100% of the buyers willing to buy at that price actually see the offer in a reasonable amount of time - at the best price the seller will get there will be only a single buyer after all so you need that solid proof that said buyer was actually able to get the offer. In fact, I don't think the seller will care enough about this to pay the proof of publication fee either. Assuming sellers can either broadcast the order on a bitmessage-like network or use your proof of publication scheme, the later will be always be more expensive. So my prediction is that most people will just use the simplest, fastest and cheapest method, but I guess only time can tell. 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 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. As an aside, nLockTime would be nice not to always have to double-spend the inputs of an order to cancel it. 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. -- 'peter'[:-1]@petertodd.org b52709f0485161e764ac0198960885ccab019a978322cc6e 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
Re: [Bitcoin-development] Fee drop
On Mon, Feb 24, 2014 at 11:41:16PM -0500, Peter Todd wrote: So, just to be clear, we're adding, say, a memory limited mempool or something prior to release so this fee drop doesn't open up an obvious low-risk DDoS exploit right? As we all know, the network bandwidth DoS attack mitigation strategy relies on transactions we accept to mempools getting mined, and the clearance rate of the new low-fee transactions is going to be pretty small; we've already had problems in the past with mempool growth in periods of high demand. Equally it should be obvious to people how you can create large groups of low-fee transactions, and then cheaply double-spend them with higher fee transactions to suck up network bandwidth - just like I raised for the equally foolish double-spend propagation pull-req. Of course, there's also the problem that we're basically lying to people about whether or not Bitcoin is a good medium for microtransactions. It's not. Saying otherwise by releasing software that has known and obvious DoS attack vulnerabilities that didn't exist in the previous version is irresponsible on multiple levels. Well, if your investors take money with market manipulating news stories, this is absolutely the responsible thing to do to increase shareholder value with a future opportunity to cause a crash-on-demand. Besides, if you really want microtransactions, you should be using an altcoin with faster block times, smaller market cap, and larger 'human' readable currency supply. That being said, I'd say include the change, we all know about it. What would be nice would be some exploits and attack signatures for what the DOS will look like when it hits so that those of us paying attention can make some money trading in anticipation of the market crash instead of just the guys paying for the attack. The real killer feature of Bitcoin is that we can learn from it's mistakes (and bitcoin can learn from the copycatcoins), instead of one-size-fits all fiat. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- 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
To each his own, but if I say Please don't charge me for YOUR privacy by putting junk like stealth addresses in the blockchain, I think I'd get laughed out of most rooms. 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. On Mon, Feb 24, 2014 at 09:23:12AM -0800, Mark Friedenbach wrote: Given our standardization on 128-bit security / 256-bit primitives, I can't think of any crypto related data payload which requires more than 40 bytes. Even DER encoded compressed public keys will fit in there. A signature won't fit, but why would you need one in there? There's no need to design for 64-byte hashes, and the 80-char line length comparison is a good point. As an Engineer I'd want to have a little more room as a 32-byte hash or EC point + 8 bytes identifying prefix data is the bare minimum, but it is also very important that we send a message: This is for payment related applications like stealth addresses only. Don't burden everybody by putting your junk on the block chain. On 02/24/2014 08:39 AM, Wladimir wrote: On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik jgar...@bitpay.com mailto:jgar...@bitpay.com wrote: A common IRC proposal seems to lean towards reducing that from 80. I'll leave it to the crowd to argue about size from there. I do think regular transactions should have the ability to include some metadata. I'd be in favor of bringing it down to 40 for 0.9. That'd be enough for 8 byte header/identifier32 byte hash. 80, as the standard line length, is almost asking for insert your graffiti message here. I also see no need for 64 bytes hashes such as SHA512 in the context of bitcoin, as that only offers 256-bit security (at most) in the first place. And if this is not abused, these kind of transactions become popular, and more space is really needed, the limit can always be increased in a future version. 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 -- 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 -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- 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
