Re: [Bitcoin-development] BIP to improve the availability of blocks
Although quite true, I actually agree though that there should be some sort of checksum for the blocks. Bandwidth may not be a bottleneck now (or ever), but it may be at some point. This change will help Bitcoin scale. It stopped being just a website a long time ago. For many of us, most of us, Wikipedia has become an indispensable part of our daily lives. — Jimmy Wales, Founder of Wikipedia Help protect it now. Please make a donation today: http://www.wikimediafoundation.org/wiki/Donate --- On Mon, 4/30/12, Amir Taaki zgen...@yahoo.com wrote: From: Amir Taaki zgen...@yahoo.com Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks To: bitcoin-development@lists.sourceforge.net bitcoin-development@lists.sourceforge.net Date: Monday, April 30, 2012, 3:11 PM This is optimisation where it isn't needed. Bandwidth is not the bottleneck of the Bitcoin system. It is the immense time needed to validate the blockchain. And clients should never send blocks first. They always send an inv packet, then you request the block. It is a disruptive change and brings little. We don't need to optimise every aspect of Bitcoin :) Just focus on the big bits that matter, while keeping everything working with minimal changes. For instance say we did this and to maintain backwards compatible, we introduced a new message called hash+block. Now there are 2 code branches that must be maintained - urgh. From: Wladimir laa...@gmail.com To: Rebroad (sourceforge) rebroad+sourceforge@gmail.com Cc: bitcoin-development@lists.sourceforge.net Sent: Monday, April 30, 2012 7:26 PM Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks On Mon, Apr 30, 2012 at 6:40 PM, Rebroad (sourceforge) rebroad+sourceforge@gmail.com wrote: My proposal is that in addition to the size (which is advertised in the header), the hash is also advertised in the header (of a block). This would help nodes to determine whether they wanted to reject the download. (e.g. if it already had a block matching that hash). This of course wouldn't prevent a rogue node from sending an incorrect hash, but this would aid in saving bandwidth amongst behaving nodes. I suppose it would make sense for clients to be able to reject blocks that they already have, if that's not currently possible. The other part of the proposal is to allow nodes to request upload and download blocks that have already been partially downloaded. This could be done by modifying the existing methods of upload, download, or by adding a new method, perhaps even using HTTP/HTTPS or something similar. This would also help nodes to obtain the blockchain who have restrictive ISPs, especially if they are being served on port 80 or 443. This could perhaps also allow web caches to keep caches of the blockchain, thereby making it also more available also. You don't need a BIP if you want to somehow fetch the (initial) block chain outside the bitcoin protocol. You could download it from some http server or even pass it along on an USB stick. Then with a simple client change you can import it: https://github.com/bitcoin/bitcoin/pull/883 . Currently, without this functionality, nodes with restrictive (or slow) internet have some options, such as going via a tor proxy, but due to the latency, the problem with multiple receptions of the same block still occur. If you're behind such a slow internet connection, and concerned about every bit of bandwidth, it is better to run a lightweight node. For example, Electrum. Even if you could reduce the wasted bandwidth a bit by puzzling around with partial blocks, the download will still be substantial (and that's going to get worse before it gets better). Wladimir -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing
Re: [Bitcoin-development] Alternative to OP_EVAL
I agree with Joel. I think someone brought this up earlier as well. Most
OP_EVAL transactions won't be complex enough to require more than a few loops.
--Zell
It stopped being just a website a long time ago. For many of us, most of us,
Wikipedia has become an indispensable part of our daily lives.
— Jimmy Wales, Founder of Wikipedia
Help protect it now. Please make a donation today:
http://www.wikimediafoundation.org/wiki/Donate
--- On Sat, 12/31/11, Joel Joonatan Kaartinen joel.kaarti...@gmail.com wrote:
From: Joel Joonatan Kaartinen joel.kaarti...@gmail.com
Subject: Re: [Bitcoin-development] Alternative to OP_EVAL
To: rocon...@theorem.ca
Cc: bitcoin-development@lists.sourceforge.net
Date: Saturday, December 31, 2011, 4:54 AM
Wouldn't it work to restrict the
number of executions of OP_EVAL allowed
per transaction? That way it wouldn't allow for unlimited
looping. If
there's too many OP_EVAL executions during the transaction
evaluation,
just consider the transaction illegal. 3 would be enough
for the
purposes people have been planning for here I think.
- Joel
On Thu, 2011-12-29 at 11:42 -0500, rocon...@theorem.ca
wrote:
On Thu, 29 Dec 2011, theymos wrote:
On Thu, Dec 29, 2011, at 01:55 AM, rocon...@theorem.ca
wrote:
The number of operations executed is still
bounded by the number of
operations occurring in the script.
With the OP_EVAL proposal the
script language becomes essentially Turing
complete, with only an
artificial limit on recursion depth
preventing arbitrary computation
and there is no way to know what code will
run without executing it.
Even if OP_EVAL allowed infinite depth, you'd
still need to explicitly
specify all operations performed, since there is
no way of looping.
That's not true. Gavin himself showed how to use
OP_EVAL to loop:
OP_PUSHDATA {OP_DUP OP_EVAL} OP_DUP OP_EVAL.
Basically OP_DUP lets you duplicate the code on the
stack and that is the
key to looping. I'm pretty sure from here we get
get Turing completeness.
Using the stack operations I expect you can implement
the SK-calculus
given an OP_EVAL that allows arbitrary depth.
OP_EVAL adds dangerously expressive power to the
scripting language.
--
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] Protocol extensions
I may be missing something, but perhaps the simplistic method is the best. Start all nodes off with a certain level of trust. Lets choose an arbitrary number 5. If a node's trust level is high enough (lets say 10) forward transactions it sends you without checking them. If a node's trust level is low enough (lets say 0) discard any transactions they send you (i.e. don't forward them on). For nodes with a trust level between 1 and 9, forward without checking between 1 and 9 out of every 10 transactions. Check the others, if they are valid, increase the trust level by 1, if they are invalid decrease the trust level by 3. All of the numbers mentioned here (1-10, 1, 10, 1, 5, and 3) are arbitrary numbers that should be determined by the client or user-preferences instead of the protocol. This would allow for clients to have varying amounts of initial trust/paranoia about their peers. By decreasing the amount of trust faster than we increase it, we make it harder for untrustworthy clients to cheat us. By having a cut off point, we make it so that untrustworthy clients can not DDoS us. By randomly verifying some transactions in the beginning, we make it harder for a new client from DDoSing us, and we prevent our own trust level from being hurt too much for forwarding on invalid transactions. The only problem I can personally see with this system is that if Node A trusts Node B with a 10 and Node C connects to Node A, then Node C can send transactions that are invalid to Node C via Node A without Node C being any the wiser. This would be stopped fairly quickly as Node B would catch on and stop forwarding transactions, but it would be a problem for new Nodes. This could be fixed (somewhat) by having a message that says not to trust a particular node. --Zell Faze --- On Thu, 12/22/11, Andy Parkins andypark...@gmail.com wrote: From: Andy Parkins andypark...@gmail.com Subject: Re: [Bitcoin-development] Protocol extensions To: Joel Joonatan Kaartinen joel.kaarti...@gmail.com Cc: bitcoin-development@lists.sourceforge.net Date: Thursday, December 22, 2011, 9:46 AM On 2011 December 22 Thursday, Joel Joonatan Kaartinen wrote: On Thu, 2011-12-22 at 11:52 +, Andy Parkins wrote: Why should they have to? Joining the network as a node is very low cost to the other nodes. You can't force any node not to be lazy, since their option is to disconnect themselves. As to maliciousness, that is defended against because when a node negative announces a transaction, that transaction is going to be checked (note that there is still no implicit trust) -- if a node is incorrectly negative-announcing then it can justifiably be kicked. a node that is not doing any checking themselves can not reliably forward failed verifications without getting the blame for doing faulty work. Those nodes would then have the incentive not to relay the failed verifications. This ends up making it important to know which nodes will be checking transactions or not so you don't isolate yourself from other nodes that are also checking transactions. Yes; I appreciate that. It's the very point I'm making. A node can choose what work to do, and should have a way of forwarding the results of that work to other nodes. Transaction verifification is the main one. Once a negative-announce message exists, it wouldn't be hard to have the other two you need as well: positive-announce and neutral-announce. At present we have only neutral-announce. However, as the need for super nodes and distributed verification gets bigger, having the forwarder able to offer an opinion on the quality of a transaction seems ideal to me. Dishonesty will get you isolated pretty quickly if you use positive-announce and negative- announce to lie. The problem with this is that it requires a web of trust as well as a web of connections. The only way to gain an advantage from this classified forwarding is if you have some way of assigning enough trust so that you can forward a classified transaction _without_ checking it yourself. That doesn't sound like an easy problem though. Andy -- Dr Andy Parkins andypark...@gmail.com -Inline Attachment Follows- -- 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 -Inline Attachment Follows- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Could we combine this proposal and the HTTPS proposal? The DNSSEC TXT record could give instructions on how to query an HTTPS server to get the address. Then we get the dynamism of HTTPS without having a rigid URL scheme for querying the server along with the advantages of DNSSEC. --- On Wed, 12/14/11, Rick Wesson r...@support-intelligence.com wrote: From: Rick Wesson r...@support-intelligence.com Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases To: Luke-Jr l...@dashjr.org Cc: bitcoin-development@lists.sourceforge.net Date: Wednesday, December 14, 2011, 8:22 PM understand that not *everyone* wants or will adhere to that best practice and in my NSHO it isn't. -rick 2011/12/14 Luke-Jr l...@dashjr.org: On Wednesday, December 14, 2011 6:02:25 PM Rick Wesson wrote: I also am largely in favor of using secured zones to publish TXT records to digital currencies. I've been thinking mainly about TXT using the following format for bitcoin. _btc.lhs.rhs Don't confuse BTC (Bitcoin unit) with BC (Bitcoin in general / protocol)... The hard part of using DNS will be sticking to the standard good practice of using a new address for every transaction. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
It is a lot easier to set up an HTTP server to dynamically respond with addresses than a DNS record. It is considered a good practice to use a different address for every payment. It stopped being just a website a long time ago. For many of us, most of us, Wikipedia has become an indispensable part of our daily lives. — Jimmy Wales, Founder of Wikipedia Help protect it now. Please make a donation today: http://www.wikimediafoundation.org/wiki/Donate --- On Wed, 12/14/11, Kyle Henderson k...@old.school.nz wrote: From: Kyle Henderson k...@old.school.nz Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases To: Zell Faze zellf...@yahoo.com Cc: Luke-Jr l...@dashjr.org, Rick Wesson r...@support-intelligence.com, bitcoin-development@lists.sourceforge.net Date: Wednesday, December 14, 2011, 11:56 PM Just so we're clear, what is the need for HTTP at all? A query for a string and an answer can all be handled via DNS. On Thu, Dec 15, 2011 at 4:57 PM, Zell Faze zellf...@yahoo.com wrote: Could we combine this proposal and the HTTPS proposal? The DNSSEC TXT record could give instructions on how to query an HTTPS server to get the address. Then we get the dynamism of HTTPS without having a rigid URL scheme for querying the server along with the advantages of DNSSEC. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
