Re: [Bitcoin-development] A bitcoin UDP P2P protocol extension
On 03/23/2013 11:24 AM, Jeff Garzik wrote: On Sat, Mar 23, 2013 at 10:52 AM, Luke-Jr l...@dashjr.org wrote: On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote: Introducing super-nodes with thousands of connected peers can greatly help here. UDP is connectionless. I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/ It depends on the usage. Simply broadcasting a TX or INV to a remote peer does not require a connection, clearly... but you probably want to signal acceptance of those messages somehow. But other uses, like subscribing to a broadcast, does require some notion of an association. In the rough draft, a parallel TCP connection with version/verack sequence is required, and you may make use of it if a connection is needed. But that is just one approach. A more robust, heavyweight UDP P2P might be a hole-punching TCP alternative. It's up to the community and results of experimentation. Bittorrent has evolved a full transfer protocol over UDP, to get around firewalls and the like. Bittorrent uses UDP in 2 ways and for different reasons. The tracker protocol is now UDP because large trackers are under such enormous strain from short lived HTTP connections (40Gb/s) that there have been instances of upstream routers becoming overloaded from the storm of SYN, ACK and FIN messages. UDP helps solve that. The inter-peer protocol is now UDP because TCP does not play nice in the context of bufferbloat and Bittorrent needs lots of active TCP connections to work, exacerbating the problem. In this instance Bittorrent uses a full userspace TCP stack which just sends w/ UDP. +1 for experimenting with UDP, we might learn some interesting things. It's worthwhile to actually speed test UDP v. TCP because the time to send an INV on an established TCP connection with Nagle disabled may not be significantly longer than that for sending with UDP. Also +1 for experimentation with sending a small transaction instead of an INV, if INVs are not being grouped because we want the fastest possible network propagation, they are mostly overhead anyway. If b/w is more important than propagation speed then of course TCP/Nagle is the way to go. Thanks, Caleb -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On-going data spam
An approach which I see as workable in the long term is to keep the block header and an array of bitfields representing each transaction's spent and unspent outputs. When someone wants to spend money you ask them for the transaction and ideally you ask them for the transaction and the merkle branch from that transaction to the header. If they want to spend the money they have to carry around the data. Agreed on the legality aspect but another case which is worth considering is what anti-virus software might do when certain streams of bytes are sent across the tcp socket or persisted to disk. Perhaps worth contacting an AV company and asking what is the smallest data they have a signature on. Thanks, Caleb On 04/09/2013 06:42 AM, Mike Hearn wrote: OK, as the start of that conversation is now on the list, I might as well post the other thoughts we had. Or at least that I had :) It's tempting to see this kind of abuse through the lens of fees, because we only have a few hammers and so everything looks like a kind of nail. The problem is the moment you try to define abuse economically you end up excluding legitimate and beneficial uses as well. Maybe Peters patch for uneconomical outputs is different because of how it works. But mostly it's true. In this case, fees would never work - Peter said the guy who uploaded Wikileaks paid something like $500 to do it. I guess by now it's more like $600-$700. It's hard for regular end users to compete with that kind of wild-eyed dedication to the cause. The root problem here is people believe the block chain is a data structure that will live forever and be served by everyone for free, in perpetuity, and is thus the perfect place for uncensorable stuff. That's a reasonable assumption given how Bitcoin works today. But there's no reason it will be true in the long run (I know this can be an unpopular viewpoint). Firstly, legal issues - I think it's very unlikely any sane court would care about illegal stuff in the block chain given you need special tools to extract it (mens rea). Besides, I guess most end users will end up on SPV clients as they mature. So these users already don't have a copy of the entire block chain. I don't worry too much about this. Secondly, the need to host blocks forever. In future, many (most?) full nodes will be pruning, and won't actually store old blocks at all. They'll just have the utxo database, some undo blocks and some number of old blocks for serving, probably whatever fits in the amount of disk space the user is willing to allocate. But very old blocks will have been deleted. This leads to the question of what incentives people have to not prune. The obvious incentive is money - charge for access to older parts of the chain. The fewer people that host it, the more you can charge. In the worst case scenario where, you know, only 10 different organizations store a copy of the chain, it might mean that bootstrapping a new node in a trust-less manner is expensive. But I really doubt it'd ever get so few. Serving large static datasets just isn't that expensive. Also, you don't actually need to replay from the genesis block to bring up a new code, you can copy the UTXO database from somewhere else. By comparing the databases of lots of different nodes together, the chances of you being in a matrix-like sybil world can be reduced to beyond reasonable doubt. Maybe nodes would charge for copies of their database too, but ideally there are lots of nodes and so the charge for that should be so close to zero as makes no odds - you can trivially undercut someone by buying access to the dataset and then reselling it for a bit less, so the price should converge on the actual cost of providing the service. Which will be very cheap. There was one last thought I had, which is that if there's a shorter team need to discourage this kind of thing we can use a network/bandwith related hack by changing the protocol. Nodes can serve up blocks encrypted under a random key. You only get the key when you finish the download. A blacklist can apply to Bloom filtering such that transactions which are known to be abusive require you to fully download the block rather than select the transactions with a filter. This means that people can still access the data in the chain, but the older it gets the slower and more bandwidth intensive it becomes. Stuffing Wikileaks into the chain sounds good when a 20 line Python script can extract it instantly. If someone who wants the files has to download gigabytes of padding around it first, suddenly hosting it on a Tor hidden service becomes more attractive. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
I can't see this working, if 51% of the mining power doesn't like your coins, when you create the commitment they will reject it. If the commitment is opaque at the time of inclusion in the block then I will create multiple commitments and then after revealing the commitment and spend to you I will reveal the earlier commitment which commits the coins to an address I control. On the topic of reversibility, I suspect in the long term the lack of chargebacks will create issues as criminals learn that for the first time in history, kidnap ransom is effective. Suffice to say after the first = $10mn kidnapping-for-bitcoin heist, governments will be forced to decide how they view the system. It will likely fall somewhere between arrest/question anyone identified holding tainted coins to something nonsensical and reactionary like blocking bitcoin as Iran does TOR. Thanks, Caleb On 05/15/2013 07:49 AM, Adam Back wrote: On Wed, May 15, 2013 at 07:19:06AM -0400, Peter Todd wrote: Protocols aren't set in stone - any attacker that controls enough hashing power to pose a 51% attack can simply demand that you use a Bitcoin client modified [to facilitate evaluation of his policy] Protocol voting is a vote per user policy preference, not a CPU vote, which is the point. Current bitcoin protocol is vulnerable to hard to prove arbitrary policies being imposable by a quorum of 50% miners. The blind commitment proposal fixes that, so even an 99% quorum cant easily impose policies, which leaves the weaker protocol vote attack as the remaining avenue of attack. That is a significant qualitative improvement. The feasibility of protocol voting attacks is an open question, but you might want to consider the seeming unstoppability of p2p protocols for a hint. Adam -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
On 05/15/2013 12:21 PM, Adam Back wrote: On Wed, May 15, 2013 at 08:40:59AM -0400, Caleb James DeLisle wrote: If the commitment is opaque at the time of inclusion in the block then I will create multiple commitments and then after revealing the commitment and spend to you I will reveal the earlier commitment which commits the coins to an address I control. Bit-commitments are based on deterministic one-way functions eg like SHA1( SHA256( public key ) ) Obviously it has to be a different one-way function to the coin address calculation which is RIPEMD( SHA256( public key ) ) as that is already public. Alternatively it can be a different serialization using the same hash eg RIPEMD( SHA256( 1 || public key ) ). Ahh thanks for clearing that up, although it would limit the possibilities of scripting it is silly of me not to think of it. There is only one commitment possible per public key - so you can only create one commitment that would validate to a receiver, or to the network. The network checks that there are no non-blind double spends of committed coins which it can do as spends require disclosure of the public key, which allows existing commitments to be verified, and it similarly qchecks that there are no blind double-commitments. Each committed coin would be: one-spend-commit = Com( spender pub ), Com( transaction ) where Com is implemented as the above hash. The network just places the commitments in order as with conventional transactions. The committed coins are not linkable to your non-blind coin because you did not reveal your public key in the (largely passive) act of receiving to a coin address. On the topic of reversibility, I suspect in the long term the lack of chargebacks will create issues as criminals learn that for the first time in history, kidnap ransom is effective. The temporary unlinkability (until commitment reveal) is a necessary side effect, not a cryptographic anonymity feature like zerocoin. The transactions are identical to bitcoins once revealed. How long the committed transaction chains can be between reveals is an implementation choice could be 1 hop, or as long as you like. (Actually it appears to be up to the individual users how long the maximum chain they accept is - the network itself, though ordering the committed spends (if there are multiple spends on the same key) cant even tell how long the commitment payment chains are). Obviously the first coins in the network ordered committed coins on the same key up to the coin value are spends as verified by the recipient, the rest are double-spend and ignored. If someone wants to waste fees by sending more spends than there inputs thats up to them. Probably the typical user doesnt care about long committed chains other than their wallet will bloat if the chains are too long, so probably they would periodically compact it by revealing the long chains. Committed coins are probably a bit less SPV client friendly, though with correct formatting in the merkle trees between blocks, probably a committed coin holder can provide enough proof to an SPV client to verify even multi-spend committed coins directly (without a network feed). About privacy, up to the entire commitment chain can be opened at any time (to other people or to the bitcoin network in general) with the cooperation of any user on the chain (up to the point they saw it), so while the blind commitment protocol is not vulnerable to a 50% power quorum unilaterally imposed policy (without even needing client updates), it is fully dependent on the good will of the recipients for its temporary unlinkability. Thats the point: it puts policy control in the users hands not in the 50% power quorum. That is indeed interesting. If I understand this properly Alice commits coins to pay to Bob and gives Bob the transaction, Bob then commits to pay to Charlie and gives him the related transaction. If Charlie wants to collect the bitcoin he then reveals Alice's transaction and Bob's. I think what you're trying to do is *almost* possible now (ab)using BIP-0016 In the output of the previous tx you put: OP_HASH160 [20-byte-hash-value] OP_EQUAL and in the next tx you use a new type of input which specifies it's value but not the output which is spent. In the input script you place: OP_DUP OP_1ADD OP_HASH160 [20-byte-hash-value] OP_EQUALVERIFY Then a serialized script containing the normal stuff as well as the last transaction hash and output index would be passed around out of band and the validating nodes would execute each script with a shared stack, beginning with the out of band one, then the input one (the OP_EQUALVERIFY) then the output. When the serialized sigscript reaches the bottom of the stack, having been verified twice, it will now be evaluated as per the rules of P2SH. None of this probably works in the real world since I'm not familiar with the actual implementation
Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)
Not only does the size of the proof grow endlessly as the coin is passed around, the size of the UTXO set grows endlessly as more and more of the already spent coins cannot be proven to have been spent because the proofs are passed out-of-band. I never said the idea was good, just interesting :) Thanks, Caleb On 05/15/2013 10:45 PM, Gregory Maxwell wrote: On Wed, May 15, 2013 at 7:22 PM, Mike Hearn m...@plan99.net wrote: Conceptually it sounds a lot like ZeroCoin (not in implementation)? Zerocoin conceals the connection from everyone forever, assuming the underlying trapdoor problem is computational infeasible, but at great cost. Adamcoin, depending on how its done, at most conceals the transactions from people who aren't a party to them... though as time goes on eventually everyone becomes a party to a sufficiently old coin, and avoiding publication creates quadratic costs in evaluating a private clique's claims so instead an implementation would make the identities public but only once they're burred a bit. Perhaps an extreme version of the idea is easier to understand. Ignore DOS attacks for a moment and pretend there is never any address reuse: Everyone creates txouts paying a P2SH addresses that have a OP_PUSH nonce in them and tell you recipient the nonce out of band. When the recipients spend those coins they provide the script but not the nonce. The recipient knows what coins he's spending, but the public does not. The public can tell there is no double spend though, because they'd see the same script twice. The person he's paying may be skeptical that he actually has any coin and didn't just mine some gibberish, but our spender tells that their receiver the nonce, and that person can see the coin available for spending in the chain and also see that there are no double spends. This could actually go on forever with no ambiguity over who owns what, but the out of band proofs that you have to give people when you spend coins would grow with the history of the coins. Since there wouldn't be much privacy once a transaction was sufficiently split up in any case, you instead just publish the unblindings once transactions are sufficiently buried. Thus bounding the growth of the proofs. The reason I say I need to internalize this more is mostly that I need to think about attacks on the publication for 'tained' transactions being more or less isomorphic to just refusing to allow spending of the 'tainted' coins in any case. -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Revocability with known trusted escrow services?
IMO this story falls somewhere between rose colored glasses and outright trolling. Whereas LR was a (relatively shady) company, bitcoin is an entire branch of technology and research, I can't think of any real caselaw in the US with regards to banning a technology, perhaps the cryptography export regulation and we all know how well that worked. Furthermore, the non-reversibility of LR is mostly because they didn't want to deal with mediation while the non-reversibility of bitcoin is technological barrier. It seems AmericanBanker has a record of hosting articles which urge policy decisions: http://www.americanbanker.com/bankthink/governments-must-co-opt-bitcoin-to-avert-disaster-1058380-1.html that would obviously be of personal benefit to the article's author: http://www.clearbit.com/company_management.htm It is the very job of governments to resist the efforts of lobbyists to line their pockets at the public expense. While I don't think significant risk of developed countries actually banning an entire area of research such as bitcoin, I do suspect that bitcoin's popularity lead to LR's downfall as it will other companies which allow people to transact anonymously. The tragedy of bitcoin's irreversibility is that it makes kidnap/ransom schemes profitable. The relative safety of the first world is largely due to the fact that until now, there has never been any effective way to steal significant amounts of money. While this problem is serious I don't think it's intractable. Bitcoin offers us a modeling tool which like never before allows us to experiment with our motivations and build something better than even bitcoin is today. I believe regulators are intelligent people who understand this and would rather legitimize bitcoin than ban it. If there ever were such a ban, I would be more concerned for the future of the country imposing it than I would for bitcoin. Thanks, Caleb tl;dr haters gonna hate On 06/06/2013 06:22 PM, Melvin Carvalho wrote: On 6 June 2013 02:19, Peter Vessenes pe...@coinlab.com mailto:pe...@coinlab.com wrote: So, this http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1 article got posted today, noting that FinCEN thinks irrevocable payments are money laundering tools. I will hold my thoughts about the net social good of rent-seeking large corporations taking money from consumers over fraudulent reversals. Actually, I won't, I just said it. At any rate, it got me thinking, can we layer on revocability somehow without any protocol change, as an opt-in? My initial scheme is a trusted (hah) escrow service that issues time promises for signing. If it doesn't receive a cancel message, it will sign at the end of the time. The addresses would be listed by the escrow service, or in an open registry, so you could see if you were going to have a delay period when you saw a transaction go out. This seems sort of poor to me, it imagines that mythical thing, a trusted escrow service, and is vulnerable to griefing, but I thought I'd see if some of the brighter minds than me can come up with a layer-on approach here. When I think about it, I can imagine that I would put a good number of my coins in a one day reversible system, because I would have warning if someone wanted to try and spend them, and could do something about it. I'm not sure if it gets me anything over a standard escrow arrangement, though. Also see satoshi's comments on this, though it may be restating what others have said: https://bitcointalk.org/index.php?topic=750.0 Here's an outline of the kind of escrow transaction that's possible in software. This is not implemented and I probably won't have time to implement it soon, but just to let you know what's possible. The basic escrow: The buyer commits a payment to escrow. The seller receives a transaction with the money in escrow, but he can't spend it until the buyer unlocks it. The buyer can release the payment at any time after that, which could be never. This does not allow the buyer to take the money back, but it does give him the option to burn the money out of spite by never releasing it. The seller has the option to release the money back to the buyer. While this system does not guarantee the parties against loss, it takes the profit out of cheating. If the seller doesn't send the goods, he doesn't get paid. The buyer would still be out the money, but at least the seller has no monetary motivation to stiff him. The buyer can't benefit by failing to pay. He can't get the escrow money back. He can't fail to pay due to lack of funds. The seller can see that the funds are committed to his key and can't be sent to anyone else. Now, an economist would say that a fraudulent seller could start negotiating, such as release the money and I'll give you half of it back, but at
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
On 06/27/2013 01:56 PM, Gregory Maxwell wrote: On Thu, Jun 27, 2013 at 10:10 AM, Jim jim...@fastmail.co.uk wrote: Let me know if you think this is a good idea (or not!) and if you have any questions. Being able to promote a fast SPV desktop wallet would be great! I went through an cycle of testing on multibit after I saw some complaints when it went up on the page before without at lot of discussion. There were a number of issues with it at the time, in particular the frequent deadlocks— though Mike was saying that those should be fixed. I see some of the the other things that were concerning for me at the time are still uncorrected though, e.g. no proxy support (so users can't follow our recommended best practices of using it with Tor), If I were a Bitcoin dev, I would not want to talk about anonymity or TOR because that's likely to attract people with paranoid dilutions and they're really terrible users to support :) Also yay for promoting fast, easy to use clients for casual users! Thanks, Caleb that it reuses addresses (esp for change), that it doesn't clearly distinguish confirmation level. It also make repeated https connections to 141.101.113.245? (I'm not seeing the IP in the source, and it doesn't have a useful reverse dns entry, so I can't tell what its for). Is there any timeframe for changing any of this stuff? -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org
Java (Applet) security is indeed abysmal but lets compare apples to apples. With an applet some random guy with a website makes up some Java code and your browser automatically executes it. With Multibit you're only executing highly trusted code (so trusted that it handles your money). There has almost never been a Java exploit against secure trusted code. The idea of discouraging use of java apps just because people would be tricked into activating the browser plugin when installing the JVM is probably valid but Multibit is the only reasonably complete client outside of bitcoinqt and I think client diversity is more important than stamping out java. Thanks, Caleb On 07/08/2013 08:22 PM, Robert Backhaus wrote: But... Multibit is Java. Java's security problems has made it an instant uninstall item on windows PCs for about a year now. Java exploits are a dime a dozen. Yes, you can reduce some of the problems by manually disabling the browser plugin, but how many users will do that? Recommending a fast SPV client as a first wallet - yes, of course. Recommending users open such a huge attack interface on their computers by installing Java - No go. Until Multibit is provided as a compiled binary without a Java dependency, it is DOA. On 1 July 2013 02:39, Gary Rowe g.r...@froot.co.uk mailto:g.r...@froot.co.uk wrote: I've beefed up the supporting documentation for the website to make it more accessible for developers who wish to contribute. It's a Java application serving HTML. It can be found here: https://github.com/jim618/multibit-website On 30 June 2013 16:19, Jim jim...@fastmail.co.uk mailto:jim...@fastmail.co.uk wrote: Yeah email jim' was never going to work so I have bumped up MultiBit support (a bit) by: + having a dedicated Support page on the website https://multibit.org/support.html It has fixes and support notes for the most common gotchas. + the in-app help also now has a 'Support' section with Troubleshooting' and the commonest gotchas. I've also written more help to cover as much as possible. + Failing that people are directed first to bitcoin.stackchange.com http://bitcoin.stackchange.com (I have a notification set up for the 'multibit' keyword. + Then finally users are directed to the github issues to search existing or raise a new issue. Gary and Tim often chip in on there to close issues down as well as me. On Sun, Jun 30, 2013, at 12:42 PM, Mike Hearn wrote: Sounds like we have consensus, Saivann, shall we do it? I'm also going to ask Theymos again to relax the newbie restrictions for the alt client forums. It's probably too hard to get support at the moment and email jim doesn't scale at all. On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen gavinandre...@gmail.com mailto:gavinandre...@gmail.com wrote: I vote yes to have MultiBit replace Bitcoin-Qt as the recommended desktop wallet app. I think most users will be happier with it. If I'm wrong, it is easy to change back. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- https://multibit.orgMoney, reinvented -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
