Re: [Bitcoin-development] does stubbing off Merkle trees reduce initial download bandwidth?
It can speed up the initial chain download. A newly created wallet will have only new key-pairs, hence no incoming transactions (unless we have a key collision, which is unlikely). So there is no need for a bootstrapping node to download the chain with transactions. The chain itself can be verified without the transactions. Later full blocks would be required to detect usable inputs for future outgoing transactions. As long as you verify the very last blocks in the chain you can be sure that all preceeding blocks were also valid. HTH, Chris On Mon, Jan 2, 2012 at 6:04 AM, Elden Tyrell tyrell.el...@gmail.com wrote: Satoshi's paper mentions that storage requirements for the blockchain can be reduced by deleting transactions whose outputs have been spent. If I understand correctly, this technique can only be used for reducing *storage* requirements, not *bandwidth* needed for the initial chain download by a high-security client that doesn't trust any of its peers -- right? The rule is trust the longest valid chain of blocks. Part of a block being valid is that each transaction's inputs are unspent and their sum exceeds the transaction's outputs unless it is a coinbase. This cannot be verified for stubbed out transactions -- they have outputs but no inputs, and aren't coinbases. So a paranoid client booting up for the first time needs to be given an un-stubbed chain, right? Of course, if a client decided to accept a stubbed blocks only when the sum of the difficulties in the blocks after it exceeds some number N, then attacking it could be made very expensive by picking a large enough N. Please let me know if I have misunderstood something. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Meeting 21:00 UTC #bitcoin-dev Freenode IRC
This meeting is to discuss the new OP_EVAL changes coming to bitcoin. A good summary of the past discussion so far by justmoon can be found: http://privatepaste.com/4088b049af Hopefully this can become a weekly thing. For now this is to discuss and inform about the coming changes to bitcoin. -- Where: Freenode IRC #bitcoin-dev When: 21:00 UTC (16:00 New York time) until 22:00* What: OP_EVAL Bitcoin is starting decentralising as any healthy free thinking community should. Projects are thiving and the economy is growing. New ideas are being realised and will edge out old models disruptively. My hope is that we don't all become fractured. By having weekly regular meetings, projects can harmonise in lock step. Concepts and algorithms can be proposed and debated. You'd be surprised what having a scheduled regular platform can achieve. A soap-box on an island in central waters. For me, I don't have time to wade through IRC discussions, forum posts and mailing lists. At least if the important things are discussed in one place it makes bitcoin development and the system more accessible. Before meeting: - A wiki page is created for in advance of a weekly meeting. - Announced on forums/mailing lists. - Throughout the week talking points are added to the meeting page. After: - Log of discussion is posted online. - I will type an accessible summary for the community at large on http://bitcoinmedia.com/ - Next weekly meeting is scheduled. Amir Taaki *We can go over this hour, but this is to stop meetings dwindling off topic into banal banter and stay focused. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Alternative to OP_EVAL
Seems ... acceptable from first glance. Though I propose an ammendent to either (1) make the script: OP_NOP1 HASH160 push-20-byte-hash EQUAL to make it extremely easy to see from the first byte that this is verly likely to be a special transaction (or more accurately if the first byte isn't OP_NOP1 then you immediately know it isn't a special script and can even disregard the token). or (2) If you are feel like spending another byte make the script: OP_NOP1 push-special-script-version-number special-script and assign 1 to this special script, making this case: OP_NOP1 OP_1 HASH160 push-20-byte-hash EQUAL On Mon, 2 Jan 2012, Gavin Andresen wrote: Here are my latest thoughts on a safer OP_EVAL alternative, inspired by all the ideas and agitated IRC and email discussions of the last week or so: Goal: Let users publish a short funding address that is the hash of an arbitrary redemption Script revealed when they spend the funds, implemented in a backwards-compatible-in-the-blockchain way. Proposal: A new 'standard' transaction type, pay to Script hash: scriptPubKey: HASH160 push-20-byte-hash EQUAL Redeemed with the same scriptSig as the OP_EVAL proposal: signatures serialized Script Old clients/miners will ignore signatures and just validate that the hash of serialized Script matches. New clients/miners will recognize the new type of transaction and will do the following additional validation: 1. Fail validation if there were any operations other than push data in the original scriptSig. 2. Deserialize the top (last) item on the scriptSig stack (fail validation if it fails to deserialize properly). 3. Run an additional validation on the deserialized script, using the remaining items on the scriptSig stack and the deserialized script as the scriptPubKey. --- As Amir said in IRC chat today, the idea is a hack but I like it. I like it, too-- it is cleaner than OP_EVAL, more straightforward to implement, and pretty much exactly matches the feature I care about (moving code from the scriptPubKey to the scriptSig). There are no special cases like CODESEPARATORS not allowed in serialized script. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Alternative to OP_EVAL
+1. I love this proposal. It's two less bytes than OP_EVAL even. It allows static analysis. It doesn't require any change to the script interpreter. (You can do a static replacement step between parsing and execution.) It allows all urgent use cases. It doesn't consume a NOP. If we ever want recursion or something else, we can still add OP_EVAL,... then. @roconnor: 1. make the script: OP_NOP1 HASH160 push-20-byte-hash EQUAL to make it extremely easy to see from the first byte that this is verly likely to be a special transaction (or more accurately if the first byte isn't OP_NOP1 then you immediately know it isn't a special script and can even disregard the token). I disagree. If people actually do mean HASH160 hash EQUAL, let *them* add a NOP. Or better to avoid NOP let them use HASH160 hash EQUALVERIFY 1. Point is, if you don't want code replacement you can easily break the pattern. But code replacement will be overwhelmingly more common, so it should be as small as possible. Every byte matters. On 1/2/2012 4:59 PM, Gavin Andresen wrote: Here are my latest thoughts on a safer OP_EVAL alternative, inspired by all the ideas and agitated IRC and email discussions of the last week or so: Goal: Let users publish a short funding address that is the hash of an arbitrary redemption Script revealed when they spend the funds, implemented in a backwards-compatible-in-the-blockchain way. Proposal: A new 'standard' transaction type, pay to Script hash: scriptPubKey: HASH160push-20-byte-hash EQUAL Redeemed with the same scriptSig as the OP_EVAL proposal: signatures serialized Script Old clients/miners will ignoresignatures and just validate that the hash ofserialized Script matches. New clients/miners will recognize the new type of transaction and will do the following additional validation: 1. Fail validation if there were any operations other than push data in the original scriptSig. 2. Deserialize the top (last) item on the scriptSig stack (fail validation if it fails to deserialize properly). 3. Run an additional validation on the deserialized script, using the remaining items on the scriptSig stack and the deserialized script as the scriptPubKey. --- As Amir said in IRC chat today, the idea is a hack but I like it. I like it, too-- it is cleaner than OP_EVAL, more straightforward to implement, and pretty much exactly matches the feature I care about (moving code from the scriptPubKey to the scriptSig). There are no special cases like CODESEPARATORS not allowed inserialized script. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Meeting 21:00 UTC #bitcoin-dev Freenode IRC
Because many made the mistake and it isnt specified in this email, this meeting is tomorrow (not 30 minutes ago). On Mon, 2012-01-02 at 08:04 -0800, Amir Taaki wrote: This meeting is to discuss the new OP_EVAL changes coming to bitcoin. A good summary of the past discussion so far by justmoon can be found: http://privatepaste.com/4088b049af Hopefully this can become a weekly thing. For now this is to discuss and inform about the coming changes to bitcoin. -- Where: Freenode IRC #bitcoin-dev When: 21:00 UTC (16:00 New York time) until 22:00* What: OP_EVAL Bitcoin is starting decentralising as any healthy free thinking community should. Projects are thiving and the economy is growing. New ideas are being realised and will edge out old models disruptively. My hope is that we don't all become fractured. By having weekly regular meetings, projects can harmonise in lock step. Concepts and algorithms can be proposed and debated. You'd be surprised what having a scheduled regular platform can achieve. A soap-box on an island in central waters. For me, I don't have time to wade through IRC discussions, forum posts and mailing lists. At least if the important things are discussed in one place it makes bitcoin development and the system more accessible. Before meeting: - A wiki page is created for in advance of a weekly meeting. - Announced on forums/mailing lists. - Throughout the week talking points are added to the meeting page. After: - Log of discussion is posted online. - I will type an accessible summary for the community at large on http://bitcoinmedia.com/ - Next weekly meeting is scheduled. Amir Taaki *We can go over this hour, but this is to stop meetings dwindling off topic into banal banter and stay focused. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] does stubbing off Merkle trees reduce initial download bandwidth?
On Mon, Jan 2, 2012 at 5:23 PM, Elden Tyrell tyrell.el...@gmail.com wrote: On 2012-01-02 05:31:19 -0800, Christian Decker said: Later full blocks would be required to detect usable inputs for future outgoing transactions. Er, yes, this is what I meant; I guess I should have been more specific. So, a paranoid client cannot confirm reciept of coins until it has an unstubbed copy of the entire chain. It can do other things (like send coins) using a stubbed chain, but it needs the whole unstubbed chain in order to be sure that incoming coins haven't already been spent. Thanks for confirming this. Er, no— if a node controls the private keys for a transaction, and that transaction makes it into the chain then it can safely assume that its unspent (at least once its buried a few blocks into the chain). This is the essence of a SPV node. What it can't do is perform this function for txn which aren't its own. Though the system could be extended in a compatible manner to make this possible: https://bitcointalk.org/index.php?topic=21995.0 -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] does stubbing off Merkle trees reduce initial download bandwidth?
On 2012-01-02 14:41:10 -0800, Gregory Maxwell said: make this possible: https://bitcointalk.org/index.php?topic=21995.0 Neat! I had a similar idea but you've clearly beat me to [a big part of] it. Er, no— if a node controls the private keys for a transaction, and that transaction makes it into the chain then it can safely assume that its unspent (at least once its buried a few blocks into the chain). I'm not so sure about that. If you accept X successor blocks as proof that none of the transactions in a block re-used an output, then the cost of attacking is X*50BTC since the hashpower needed for the attack could have earned that much reward. However, an attacker could use the same faked X-block sequence to attack multiple clients by putting several double-spend transactions in the first faked block. This would spread out the cost over more than one attack. So simply checking that the value of the transaction is less than X*50 isn't necessarily enough, although the logistics of the attack aren't exactly easy. There's also the question of knowing what the difficulty for those X blocks ought to be. If the attacker controls your network connection (e.g. your ISP attacks you) you wouldn't be able to get a second opinion on how high the difficulty ought to be, and might get fooled by X very-low-difficulty blocks that were each produced with a lot less than 50BTC worth of hashpower. - e -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
