Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split?
On Wed, 24 Aug 2011 11:12 -0400, "Gavin Andresen" wrote: > To organize this discussion: first, does everybody agree? Yes. The feature will be very good. > I still think it is a good idea to enable a set of new 'standard' > multisignature transactions, so they get relayed and included into > blocks. I don't want to let "the perfect become the enemy of the > good" -- does anybody disagree? Please do enable any transactions that seem to be a possible solution. Even if this client doesn't ever implement any of them, alternative clients can try them. > My biggest worry is we'll say "Sure, it'll only take a couple days to > agree on how to do it right" and six months from now there is still > no consensus on exactly which digest function should be used, or > whether or not there should be a new opcode for arbitrary boolean > expressions involving keypairs. And people's wallets continue to get > lost or stolen. I agree that something should be done with what we have now. It *will* take months to properly figure out how to add chain-forking features for this. If we want to consider all of the unrelated feature proposals, it might take years of discussion... However, as I said in the forum thread, I think it would be better for people using this protection to receive at a normal address and then create new transactions at their end. Then no one has to handle huge addresses, and the sender will never have to pay abnormal fees or deal with incompatibilities. There will be a short period of time when the recipient's money is unprotected, but I think this is worth it. A better scheme can be made later after chain-forking features are figured out. -- EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Alert System
The alert system will be very important if there are ever any critical problems in the network. For example, it is currently Bitcoin's only defense against an attacker with >50% of the computational power, where alerts would be used to tell people to stop accepting transactions. Displaying a message is pretty harmless. In fact, I don't think the message is prominent enough. The GUI client should not allow people to see received transactions or send new transactions while an alert is in effect (with an opt-out), and there should be an opt-in feature that puts RPC into safe mode in response to an alert. Alerts are no worse than transactions as a DoS attack vector. They're much safer than typical HTTPS because there are no CAs that can break its security. (FYI: I also have a copy of the alert key.) -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Alert System
On Thursday, September 08, 2011 3:45 PM, "Luke-Jr" wrote: > I don't seem to recall this ever happening, despite Deepbit having over 50% > multiple times now. An alert would have been issued if they had abused that position. -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Difficulty adjustment / time issues
A better retarget strategy might be to use the real average time between all of the blocks in the interval so that no blocks are treated specially in the calculation. I agree that this is not important enough to fork the chain over, though. An attacker would have to maintain control for a *very* long time because of Bitcoin's long retarget interval. (Maybe this kind of thing is why the retarget interval is so long?) I don't like requiring block times to be within minutes of reality. It would be fine if only miners had to keep accurate time, but clients will also need to have good time in order to see if a block will be discouraged. A discouraged block should not count toward confirmations. If relays will also discourage blocks, then they'll need accurate time as well. The network should not be allowed to adjust your time by more than 40 minutes to prevent the timejacking attack, but I don't see a problem with the other time rules. Time is only used for retargets and LockTime, so it only needs to be generally accurate. -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Difficulty adjustment / time issues
On Wednesday, September 14, 2011 5:51 PM, "Gregory Maxwell" wrote: > General network health and user security _requires_ periodic upgrades > in any case, and will for the foreseeable future. The whole notion > that old versions will _stop working_ would be a pretty good thing at > this point in bitcoin's existence, judging by the high number of pre- > .24 listeners still reported. Backward-compatibility is valuable. I believe version 0.1 will still more or less work on the current network. This is a real selling point for Bitcoin: the code is solid enough that even 2-year-old clients are still working. -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.4.x stable branch
On Monday, September 19, 2011 11:00 AM, "Luke-Jr" wrote: > The problem with the current development model is that bugfixes are > done alongside improvements, and code changes *always* have the > potential to introduce new bugs, no matter how careful anyone is. So > to stay on top of bugfixes right now implies risking new bugs being > introduced. What good is getting one bug fixed, if it comes with 20 > new yet-to-be-discovered bugs? A stable version is a good idea. This is why I'm still using 0.3.19 (with some modifications): none of the bugfixes after this version help me much, and I don't need any of the new features. I've also thought about starting an unofficial stable version with my modifications to 0.3.19 and some backported bugfixes. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Newly introduced DoS
On Monday, September 26, 2011 5:53 PM, "Luke-Jr" wrote: > It's not future. It's presently allowed in blocks. Which means it's > perfectly valid to relay (and also perfectly value to NOT relay or > accept). Ergo, shouldn't be punished. Yeah, my node has always relayed these transactions. The limit seems pointless to me, especially when it's per kB: people will just add more data. The coinbase maturity DoS limit should not have a chance of immediately kicking the node, as I believe this could happen normally in rare cases. Rejecting these transactions is also pretty cheap, AFAIK. A small DoS score seems reasonable, though. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: bitcoin scope issue in main.cpp
It's legal for a scope to define variables with names that conflict with the names of variables in higher-level scopes. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
For now I think requiring direct-connection negotiation is best for these kinds of things. A direct connection is OK in most cases, and more complicated schemes will be more likely to fail. Maybe the IP transactions protocol can be used. In the future, I imagine that users of ultra-lightweight clients will connect to a new P2P network built on top of the core Bitcoin network in order to receive block headers and info about sent/received transactions without leeching off of the few full nodes. This network could also be used for indirect transaction negotiation, which is similar to the goal of finding your own received transactions. On Wednesday, November 09, 2011 3:02 PM, "Gavin Andresen" wrote: > a nValue=0 transaction can be considered 'immediately spent' I believe it's possible to spend a 0-value output, so they can't be considered automatically spent. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
I like the u...@server.com model. The protocol should be done entirely in DNS, though, not using HTTP connections to the server. Then the protocol can easily be used with Namecoin or other DNS replacements/enhancements later. Crypto to prevent MITM attacks can be an optional part of the protocol. Almost all users will be unable to set up *any* always-on Internet service to answer queries, so I'm not too concerned about how easy it is to set up the server software. I agree that FirstBits is bad for this. Unlike DNS, "registrations" last forever because private keys can't be transferred safely. All short names will be taken quickly. It will also be very expensive for clients to query this themselves. The CA model is broken and it should never be used by Bitcoin. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
Bitcoin already has code and a protocol for transactions to IP addresses. Why not reuse that for dynamic address lookup? Just a few changes are necessary to enable complete u...@server.com handling: - Extend the protocol so that "reply" messages can be signed by a fixed public key - Extend "checkorder" messages so they can specify an account to send BTC to. Or standardize on how to put the account into the message field. - Enable DNS lookups for IP transactions. The DNS-only proposals could also be used here to avoid having to use the IP transaction protocol sometimes. The public key for signing "reply" messages can be gotten from TXT records. This will be safe with DNSSEC and Namecoin. With plain DNS Bitcoin could take a SSH-like approach and ask the user to verify the public key the first time it is used, remembering it later. DoS attacks are already handled by the IP transactions code: the same IP address is always given the same bitcoin address until it pays to that bitcoin address. -- 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] Protocol extensions
On Sat, Dec 17, 2011, at 02:06 PM, Gavin Andresen wrote: > Although I do also wonder if we'll ever run into a problem with full > nodes refusing to answer requests from lightweight nodes (there might > be a tragedy-of-the-commons problem lurking there). This seems likely. Also, even if many full nodes are willing to donate resources, there may simply be too few full nodes to handle the load. My preferred solution for handling scalability in the future is to have lightweight clients download only headers and Merkle trees (which are both small and easy to distribute), and then require senders to contact recipients directly in order to transmit their transactions. Then lightweight clients never need full blocks to build their balances, and full nodes don't have to handle expensive queries from lightweight clients. Under this scheme, the current broadcast system could be used among full nodes for a long time. Since clients wouldn't ever need to talk to full nodes, they could form a separate network with less reliable broadcasting and perhaps a fancier network architecture. Members of the full network would connect to the most reliable members of the client network in order to broadcast headers and Merkle trees and receive transactions. Full nodes would *not* answer any client queries, so dealing with the client network would not require many resources, and miners would probably have an incentive to do it. (Creating a "separate" network like this can be done by using the services field.) I don't think requiring senders to email some data to the recipient would be too burdensome, though it's probably also possible to design a system where even offline recipients can receive transactions through the Bitcoin network. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Protocol extensions
On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote: > I don't like the idea of a header only client, unless this is just an > interim action until the full block chain is downloaded in the > background. Development of these types of clients is probably > inevitable, but I believe that this breaks the most fundamental > aspects of Bitcoin's security model. If a client has only headers, it > cannot do full verification, and it is trusting the data from random > anonymous peers. A headers-only client is much better than trusting anyone, since an attacker needs >50% of the network's computational power to trick such clients. For everyone to keep being a full node, hardware costs would need to constantly go down enough for all nodes to be able to handle enough transactions to meet demand. If hardware doesn't become cheap enough quickly enough, either some people would be unable to handle being full nodes, or the max block size wouldn't rise enough to meet demand and transaction fees would become noncompetitive. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase script parse failures
Coinbase scriptSigs aren't required to be well-formed. They're never executed. -- 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
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote: It's not just about trust, there is the robustness factor: what if he becomes sick, unavailable, hit by a bus? Others need the ability to pickup and run with it. The control over the domain (including ability to renew registration, alter nameservers) needs to be with more than one person. That's why I suggest using the same people who have control over the software project at sf,github The bitcoin.org domain is controlled by me, Sirius, and an anonymous person. Control will not be lost if Sirius becomes unavailable. SSL is probably a good idea, and it's probably also a good idea to separate bitcoin.org from Github. I don't know that I trust Github. I'm sure that you can find a sponsor for a dedicated server. Let us know if DNS changes to bitcoin.org are required. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
