[Bitcoin-development] Adding callback hooks to the satoshi client
Hey, guys. I've been writing a number of apps that require realtime event notifications, where the JSON-RPC API clearly doesn't suffice. There are two approaches I've been taking to this end: 1) Writing my own library for dealing with raw bitcoin structures and connecting to bitcoin nodes via the bitcoin protocol. 2) Making custom builds of the satoshi client putting callback hooks in key points. Neither of these two approaches is ideal. (1) involves a lot of code duplication, (2) involves patching the satoshi client source each time I grab a later version, with the everpresent risk of something breaking and the need to continue maintaining these patches. Moreover, unfortunately many of these key points happen to be in files like main.cpp which see frequent changes. I would like to propose adding these callback hooks to the main branch. I am willing to help locate these key points, reorganize the code to place these methods in separate source files, define a callback mechanism, and contribute source code. -Eric Lombrozo -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Adding callback hooks to the satoshi client
The callback architecture could be such that other code would never need to enter into the wallet-handling process/memory space. For instance, client applications could subscribe a particular URL to get sent an HTTP POST. For the apps I've been working on, there really isn't any need to access the wallet space. I was talking more about events like A new transaction was just seen or A new block was just seen, like what libcoin seems to support (sorry, Michael, I haven't really had a chance to look at it in depth but I will). Then there are other types of events for other bitcoin messages could also be useful: new addr, new node connected, node disconnected, bitcoin alert, etc... Then there are events for dealing with potential attacks: DoS attempt, double-spend attempts (two transactions seen with valid signatures claiming the same output), node sending malformed messages, etc... And then there are alerts pertaining to the status of the bitcoind process itself: bitcoind started, bitcoind ready to accept connections, bitcoind stopping, etc... None of these events require the callback subscriber to have any access to the bitcoind process/memory space and all the I/O could be done via IPC or over network sockets. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Adding callback hooks to the satoshi client
I'd also like to be able to get detailed information of message format errors for debugging other nodes that connect to bitcoind. For instance, if a transaction is rejected because the signature is invalid, I want to know this. If it's because the amount is out of range or because the output couldn't be connected, I want to know this, too. I especially want to know if it was because the transaction is claiming an output that has already been claimed by another transaction. For now, I've had to resort to sticking tracers and stubs into bitcoind. It would be really nice to not only be able to write an error log but to also let the connecting node know what went wrong. Obviously these types of messages should *not* be part of the bitcoin protocol itself since it invites all kinds of attacks. But it would be wonderful to have a side channel for this type of data, and it could also be done using callbacks. The callback mechanism could be configurable in a similar fashion to the RPC in the bitcoin.conf file. -Eric Lombrozo -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Zero-length scripts
I've noticed a few transactions that have zero-length input and/or output scripts. There's a couple examples in block 0159a27442ee8b7f9ffad0cd799b003eafe007de9fbb47bd6ce7: Txs: cdb553214a51ef8d4393b96a185ebbbc2c84b7014e9497fea8aec1ff990dae35, af32bb06f12f2ae5fdb7face7cd272be67c923e86b7a66a76ded02d954c2f94d Is there ever a legitimate reason to create a transaction with a zero-length script? Should the protocol even allow it? -Eric Lombrozo -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Simple contacts exchange (was: Social network integration (brainstorm))
Why not just use the transaction hash itself for the lookup? Also, presumably you'd want to encrypt the data so that only the recipient of the transaction can do this lookup. -Eric On Sep 6, 2013, at 8:07 AM, Wendell w...@grabhive.com wrote: Hi all, We're thinking about ways of automatically exchanging contact details between wallets, in order to encourage the proliferation of identifiable names and photos rather than long and hard-to-verify addresses. The simplest version goes like this: 2 BTC Bitcoin is sent to someone, and a data lookup hash is inserted into the transaction. When it arrives on the other end, it is indeed looked up, and instead of being presented with a dialogue that says you received 2 BTC from 13Y94z43Nbbb6wevRyk82CeDoYQ5S28zmA, it's You received 2 BTC from Frank Jones including a nice photo. Now. We can simply delete this data in reference to the transaction ID after it happens (or delete it after a time), but is there any more decentralized way to do it? I would prefer us to run no dedicated servers that would ever put us in a position of being coerced into giving data, or otherwise altering our system to store it. Any thoughts about this? -wendell grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Testnet block explorer
I've built a shell around the bitcoind JSON-RPC, along with a websockets server that provides realtime transaction and block feeds which can be used with bitcoin mainnet and testnet as well as any of the alt chains and formats it similar to blockchain.info with the bootstrap look-and-feel, i.e. http://altcoins.ws/dogecoin/ A goal of this project was simplicity in deployment to a new server. The JSON-RPC is missing address indexing and an unspent API, so these things are still missing from this shell. -Eric On Dec 27, 2013, at 11:23 AM, Melvin Carvalho melvincarva...@gmail.com wrote: On 27 December 2013 19:08, Mike Belshe m...@belshe.com wrote: Great! There is another one at http://testnet.btclook.com/ which provides a different view as well. And another at: http://test.webbtc.com/ Testnet does not currently fully function with for creating transactions: http://test.webbtc.com/ Because there's no unspent API for getting the unspent values for an address. If there existed a testnet explorer which would send out those values (as blockchain.info does with the main net), that would be awesome. I'm also working on a testnet explorer with semantic web markup so that it's both human and machine readable. Mike On Fri, Dec 27, 2013 at 10:05 AM, Mike Hearn m...@plan99.net wrote: For a long time the only block explorer for testnet has been the original blockexplorer.com, which is unfortunately often broken / behind / slow and not really maintained any more. There is now a new one, here: https://www.biteasy.com/testnet/blocks There's also a REST/JSON API for it. Please note one curiosity of this block explorer is that the coinbase tx doesn't necessarily come first in the listing (it's sorted by time received, see). Other interesting thing to note: this site is built using bitcoinj. The author can be contacted on IRC sometimes using the nick damethos. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Testnet block explorer
I'll add testnet to it as well - sorry, Ben, for lifting the css (I'm a programmer, not a graphic designer) - if anyone would like to help me make the styling original, I would be more than happy to collaborate. -Eric On Dec 27, 2013, at 1:36 PM, Eric Lombrozo elombr...@gmail.com wrote: I've built a shell around the bitcoind JSON-RPC, along with a websockets server that provides realtime transaction and block feeds which can be used with bitcoin mainnet and testnet as well as any of the alt chains and formats it similar to blockchain.info with the bootstrap look-and-feel, i.e. http://altcoins.ws/dogecoin/ A goal of this project was simplicity in deployment to a new server. The JSON-RPC is missing address indexing and an unspent API, so these things are still missing from this shell. -Eric On Dec 27, 2013, at 11:23 AM, Melvin Carvalho melvincarva...@gmail.com wrote: On 27 December 2013 19:08, Mike Belshe m...@belshe.com wrote: Great! There is another one at http://testnet.btclook.com/ which provides a different view as well. And another at: http://test.webbtc.com/ Testnet does not currently fully function with for creating transactions: http://test.webbtc.com/ Because there's no unspent API for getting the unspent values for an address. If there existed a testnet explorer which would send out those values (as blockchain.info does with the main net), that would be awesome. I'm also working on a testnet explorer with semantic web markup so that it's both human and machine readable. Mike On Fri, Dec 27, 2013 at 10:05 AM, Mike Hearn m...@plan99.net wrote: For a long time the only block explorer for testnet has been the original blockexplorer.com, which is unfortunately often broken / behind / slow and not really maintained any more. There is now a new one, here: https://www.biteasy.com/testnet/blocks There's also a REST/JSON API for it. Please note one curiosity of this block explorer is that the coinbase tx doesn't necessarily come first in the listing (it's sorted by time received, see). Other interesting thing to note: this site is built using bitcoinj. The author can be contacted on IRC sometimes using the nick damethos. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Making the H in HD keychains useful
I've been trying to find ways to make HD keychain wallets (BIP0032) really usable from an application development perspective. I think we all know a number of solid use cases and possible applications for the D in HD, but nobody seems to have really found a way to make use of the H in a way that is actually manageable from a usability standpoint. After pondering it a bit more, I think I've stumbled upon at least a couple issues that seem to give hints as to how we can change this. Hierarchical organizations do not generally tend to be designed up front, cast in stone. In the real world, hierarchies tend to evolve organically, growing new branches as entities differentiate themselves to different purposes. Organizations grow over time. Sometimes branches merge, sometimes branches die. This means that for HD keychains to be truly useful, they too need to be sufficiently flexible to adapt to the needs of a growing and evolving organization. It needs to be simple to create and move branches around as the need for them arises without having to plan the structure a priori. A significant problem I'm runnign into in trying to build applications around the BIP0032 standard is the lack of a clear separation between signing keys and hierarchical nodes. That's to say, a child of a node can either be used as a signing key or as a parent for new branches to the tree. From a usability standpoint, what this means is that one must be very careful in how one allocates keys from the very beginning - if one mixes signing keys with new branching nodes in the same generation, the whole thing becomes a horrendous mess. Moreover, it is impossible to generally distinguish these two fundamentally different types of objects (at least from a use model perspective) just from the extended key representation, something that is certain to create significant confusion as we try to design applications that can share these types of objects. An organization might begin as a single individual who just wants to generate signing keys for him/herself. Later on, this individual might bring on another individual or two and create new branches for them. With the current HD keychain structure, unless this individual made sure to set aside these new branches from the start, the individual is now forced to mix the new branches in at the same level of the hierarchy as the signing keys. Instead, it should be possible to branch off any node without having to worry at all about whether or not that node has been used to generate signing keys at all. A possible workaround to this issue is to always allocate a specific child for hierarchical derivation and the rest of the children for signing keys. Then to create subbranches, the specific child would be used as the new parent, effectively alternating generations between signing keys and organizational nodes. However, this solution seems pretty ugly. A better solution, IMO, is to only use BIP0032 for organizational hierarchy and have a different mechanism for generating a sequence of signing keys from a given node. This different mechanism could be used standalone by those not needing the full set of hierarchical features. For those who do want to use the hierarchical features, it could be seeded by the keys in the BIP0032 hierarchy. These individual signing keys would NEVER be represented in the same format as the organizational hierarchy nodes, thus ensuring applications can share these structures without risk of confusion. Until we make this clear distinction between organizational hierarchy (which parallels real-world organizations) and signing keys (which are merely cryptographic primitives, preferably never even shown directly to most endusers), I think we'll fail to find good ways to make the H in HD keychains useful. -Eric Lombrozo signature.asc Description: Message signed with OpenPGP using GPGMail -- 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] New side channel attack that can recover Bitcoin keys
If we don't mind sacrificing some performance when signing, there's a fairly simple way to implement a constant-time constant-cache-access-pattern secp256k1. It is based on the idea of branchless implementations of the field and group operations. Multiprecision arithmetic can be implemented branch-free by assuming fixed sized limbs and always performing dummy carry operations even when they aren't needed. The most critical field operation that could potentially leak data is the modular inverse. Again, if we don't mind a slow implementation, a simple constant-time implementation involves exponentiation by the field modulus minus two - which is a known constant. As for group operations in secp256k1, the main sources of leaks are the branchings that exist in typical implementations as well as optimizations for special inputs, i.e. http://en.wikibooks.org/wiki/Cryptography/Prime_Curve/Jacobian_Coordinates To avoid leaking any information, we can use the most general operation, Point Addition, in the following way: Always carry through the full point addition algorithm even if we get POINT_AT_INFINITY. Also, always carry through the POINT_DOUBLE operation even on unequal inputs. Store the three possible results (POINT_ADDITION, POINT_AT_INFINITY, and POINT_DOUBLE) and then do a branchless conditional swap with the output location as a final step. Branchless swaps can be performed using bitwise operations such as the examples here: https://github.com/CodeShark/cmp/blob/master/src/constant-time.h -- In the case of bitcoin, signature verification is where performance optimization is really helpful - and here there are no risks of sidechannel leaks, so we can go ahead and use the most optimal implementations. But for signing, the amount of throughput required is generally not that large and constant-time implementations will be more than adequate on typical hardware. -Eric Lombrozo On Mar 5, 2014, at 4:49 AM, Mike Hearn m...@plan99.net wrote: A new practical technique has been published that can recover secp256k1 private keys after observing OpenSSL calculate as little as 200 signatures: http://eprint.iacr.org/2014/161.pdf This attack is based on the FLUSH+RELOAD technique published last year. It works by observing L3 CPU cache timings and forcing cache line flushes using the clflush opcode. As a result, it is applicable to any x86 environment where an attacker may be able to run on the same hardware i.e. virtualised hosting environments where keys are being reused. I am not currently aware of any efforts to make OpenSSL's secp256k1 implementation completely side channel free in all aspects. Also, unfortunately many people have reimplemented ECDSA themselves and even if OpenSSL gets fixed, the custom implementations probably won't. So, IMHO this is a sign for hot wallet users to start walking (but not running) towards the exits of these shared cloud services: it doesn't feel safe to sign transactions on these platforms, so hot wallets should be managed by dedicated hardware. Of course other parts of the service, like the website, are less sensitive and can still run in the cloud. I doubt the researchers will release their code to do the side channel attack and it's rather complex to reimplement, so this gives some time for mitigation. Unfortunately the huge sums being held in some bitbank style hot wallets mean that attackers are well motivated to pull off even quite complex attacks. -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
Everything you say is true. However, branchless does reduce the attack surface considerably - if nothing else, it significantly ups the difficulty of an attack for a relatively low cost in program complexity, and that might still make it worth doing. As for uniform memory access, if we avoided any kind of heap allocation, wouldn't we avoid such issues? Anyhow, without having gone into the full details of this particular attack, it seems the main attack point is differences in how squaring and multiplication (in the case of field exponentiation) or doubling and point addition (in the case of ECDSA) are performed. I believe using a branchless implementation where each phase of the operation executes the exact same code and accesses the exact same stack frames would not be vulnerable to FLUSH+RELOAD. To be able to recover the sequence of point additions and doublings, the spy program should distinguish between consecutive doubling operations and must be able to order them with respect to point additions. Our spy program achieves this by setting the time slot to less than half the length of the group operations. With the selected curve, group add operations take 7,928 cycles on average, while group double operation take 7,601 cycles. Setting the time slot to 3,000 cycles ensures that there is an empty time slot within any group operation, allowing our spy to correctly distinguish consecutive doubles The approach I've suggested makes doubling operations indistinguishable from point additions from the perspective of cache access. On Mar 5, 2014, at 1:44 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Mar 5, 2014 at 1:31 PM, Eric Lombrozo elombr...@gmail.com wrote: If we don't mind sacrificing some performance when signing, there's a fairly simple way to implement a constant-time constant-cache-access-pattern secp256k1. It is based on the idea of branchless implementations of the field and group operations. Do take care that branchless doesn't mean side-channel free: On non-trivial hardware you must have uniform memory accesses too. (and that itself isn't enough for sidechannel freeness against an attacker that can do power analysis... then you star worrying about the internal structure your primitive adders and the hamming weight of your numbers, and needing to build hardware that uses differential logic, and yuck yuck yuck: This is why you still shouldn't reuse addresses, and why a blinding approach may still be sensible, even if you believe your implementation is hardened against side-channels) signature.asc Description: Message signed with OpenPGP using GPGMail -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys
Oh, I absolutely agree that this type of attack is NOT the weakest link in security. There are MANY far easier targets in bitcoind and typical use scenarios of it. If we want to dramatically improve the security of a typical bitcoin wallet, the FLUSH+RELOAD attack is probably not where our efforts would be best rewarded trying to prevent. However, this thread IS about this particular attack vector - and my suggestion IS specific to this thread. -Eric Lombrozo On Mar 5, 2014, at 2:17 PM, James Hartig fastest...@gmail.com wrote: On Wed, Mar 5, 2014 at 2:39 PM, Peter Todd p...@petertodd.org wrote: More important though is you shouldn't be using single factor Bitcoin addresses. Use n-of-m multisig instead and architect your system such that that every transaction that happens in your service has to be authorized by both the online server(s) that host your website as well as a second hardened server with an extremely limited interface between it and the online server. This adds a very minor amount of security, if any, if someone manages to hack into your hot wallet server they can just initiate a non-multisig transaction and still steal all your bitcoins in that wallet. You can't give the argument that the RPC API is password protected because the password is stored in plain-text in the config so all someone has to do is first grep for the file. There doesn't appear to be a way to force ALL outgoing transactions to be multisig and even if there was one, would you be able to force one of the addresses to be the hardened server? That still wouldn't prevent anyone from just stopping bitcoind, changing the config, then restarting it. Unless you're using your own custom wallet software there doesn't seem to be any sufficient way to prevent someone from stealing all your money once they have access to your server. Other software, like MySQL has access controls so I can prevent ALTERs, DROPs, DELETEs, etc for all live accounts limiting the scope of any attack if they manage to get into the server. Maybe this is beyond the scope of bitcoind, not sure. Thanks, -- James Hartig Software Engineer @ Grooveshark.com http://twitter.com/jameshartig -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Subversion Kills Productivity. Get off Subversion Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
Ciphrex CoinVault (https://ciphrex.com) is currently using parallel trees with lexicographic sorting of keys. CoinVault is also using a partially signed transaction format whereby 0-length placeholders are used for missing signatures in the transaction scripts. Once all the required signatures to satisfy the policy are present, the remaining zero-length placeholders are removed so the transaction can be broadcast to the network. These partially signed transactions can be shared with other parties to an account or other signing devices for the purpose of requesting additional signatures. -Eric On Mar 11, 2014, at 7:35 PM, Alan Reiner etothe...@gmail.com wrote: I might as well throw in a word about Armory. After our next release in a couple weeks, we will be going full-speed at new wallets and BIP32 integration. Just like Jean-Pierre mentioned, we'll be using parallel trees to generate P2SH addresses after sorting the keys lexicographically. We plan to introduce the concept of a wallet bundle (that name is far from concrete... I'd love a better word). All wallets in a bundle are protected by the same backup, and stored in the same file. The default behavior will be use new branches in the same BIP32 tree when a user creates a new wallet, though we will allow multiple bundles in advanced and expert usermode (which is needed to have watching-only wallets from a different seed created from an offline computer). However, we do plan to allow separate parties to create multisig-intended wallets with public parts that can be exported and combined with other users. We feel this is critical, as it allows for linked wallets in which there was never a single-point of failure from key-generation to signing. This is especially important for contexts where employees may be handling a company's Bitcoins wallets. On this topic, I have gotten a lot of inquiries into BIP 38 and 39. I was not clear whether those BIPs were worth prioritizing ... i.e. is there a general consensus from a variety of wallet developers that they should be supported? Rather, I'm happy to start prioritizing them if others do too, but I haven't spent much time trying to understand them to even know if they're mature, yet. -Alan On 03/11/2014 08:29 PM, Jean-Pierre Rupp wrote: Hello people, We are working on some of this stuff. We had some very early draft on how we envisioned multisig happening. It is all implemented in Haskoin available as multiple repositories in Github. I am happy to see this gathering momentum. Our multisig system uses BIP-0032 HD wallets, and there will soon be BIP-0039 support for keys compatibility. Our wallet uses synced trees rooted at the extended pubkeys of the participants. Currently we are sorting public keys in the scripts to avoid ambiguity. Download haskoin-wallet: cabal install haskoin-wallet Check out the hw command (installed in ~/.cabal/bin/hw). Use importtx to bring transactions into the wallet. You must initialize first with a seed and create an account. It supports both regular and multisig accounts. Perhaps this can lead to interesting discussions on key exchange, and the appropriate handling of wallet metadata. I’d love to work on a proper standard that could lead us to compatible implementations. This document explains how we do it now: http://haskoin.com/~xeno/hd-multisig-wallet.html Cheers! -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download
Re: [Bitcoin-development] BIP32 - invalidation
Does bitcoin properly handle the case of a hash collision? no - because it is considered too unlikely. The case of I_L = n is also astronomically unlikely, so it's more a matter of improved performance and simpler data structures under expected circumstances and taking that less than 1 in 2^127 chance that it will fail, in which case we can recover by moving everything over to a new tree. -Eric Lombrozo On Aug 9, 2014, at 5:34 PM, second isogeny secondisog...@gmail.com wrote: Does anyone see any concerns when it comes to security of the proposed change? Yes. This proposal is less secure. It is incompatible in theory with existing implementations of the specification. The incompatibility is also a potentially a security problem because it may cause users to believe a key is worthless when it is not or to lose funds when they are unable to spend them. It is also an untimely proposal and would be inconsiderate other parties who have done the work to produce correct and compatible implementations. In case I_L = n assign I_L := I_L mod n. This will make the selection of private keys uneven. The unevenness is small and it is unlikely to very matter much but it is objectively less secure. Future advances in cryptography may make the distinction more important. The change would eliminate any hope of the specification ever having provable security equal to random keys. The bignum modulo operation also requires complex additional logic and is just as likely to remain untested in implementations, though unit-testing can test these cases by replacing the hash function. Because of layering no suitable modulo may be available and an incorrect implementation could create a devastating weakness, like reflecting a large class of keys to a small number of values. A similar error would be unlikely for an incorrect implementation of skipping and someone who managed to still fail would likely have failed either way. most of the implementations don't do the checking at all, because tjen it's rather hard at application level to implement skipping logic. OTOH There are many corner cases which must be handled in cryptographic software. You must handle the point at infinity cases, you must handle the signature having a value of zero (or you leak the private key), in the point arithemetics you must handle the special case of adding colinear points. If someone is unprepared to deal with these and many other complications they may want to leave writing this kind of software for other people. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
I would highly recommend NOT using Base58 for anything except stuff that is to be copy/pasted by the enduser. Internally, pubkeys are DER-encoded integers. - Eric On Jan 14, 2015 2:54 PM, Jeffrey Paul j...@eeqj.com wrote: On 20150114, at 09:39, devrandom c1.sf-bitc...@niftybox.net wrote: At CryptoCorp we recommend to our customers that they sort lexicographically by the public key bytes of the leaf public keys. i.e. the same as BitPay. To clarify: the raw bytes of the public key itself, not the ascii base58 representation of the pubkey hash - right? -jp -- Jeffrey Paul EEQJ j...@eeqj.com https://eeqj.com +1-800-403-1126 (America) +1-312-361-0355 (Worldwide) 5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2 -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
I think everyone is pretty much following this standard now. - Eric On Jan 14, 2015 12:58 PM, devrandom c1.sf-bitc...@niftybox.net wrote: At CryptoCorp we recommend to our customers that they sort lexicographically by the public key bytes of the leaf public keys. i.e. the same as BitPay. On Wed, 2015-01-14 at 17:37 +0100, Ruben de Vries wrote: For p2sh multisig TXs the order of the public keys affect the hash and there doesn't seem to be an agreed upon way of sorting the public keys. If there would be a standard (recommended) way of sorting the public keys that would make it easier for services that implement some form of multisig to be compatible with each other without much hassle and making it possible to import keys from one service to another. I'm not suggesting forcing the order, just setting a standard to recommend, there doesn't seem to be much reason for (new) services to not follow that recommendation. Ryan from BitPay broad this up before (https://sourceforge.net/p/bitcoin/mailman/message/32092958/) and in bitcore they've implemented lexicographical sorting on the hex of the public key. In a short search I can't find any other library that has a sorting function, let alone using it by default, so bitcore is currently my only reference. Ruben de Vries CTO, BlockTrail -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Miron / devrandom -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
I should note that my proposal does require a change to the consensus rules...but getting bitcoin to scale will require this no matter what. - Eric Lombrozo On Feb 22, 2015 3:41 AM, Eric Lombrozo elombr...@gmail.com wrote: It seems to me we're confusing two completely different motivations for double-spending. One is the ability to replace a fee, the other is the ability to replace outputs. If the double-spend were to merely add or remove inputs (but keep at least one input in common, of course), it seems fairly safe to assume it's the former, a genuine fee replacement. Even allowing for things like coinjoin, none of the payees would really care either way. Conversely, if at least one of the inputs were kept but none of the outputs were, we can be confident it's the the latter. It is possible to build a wallet that always does the former when doing fee replacement by using another transaction to create an output with exactly the additional desired fee. If we can clearly distinguish these two cases then the fee replacement case can be handled by relaying both and letting miners pick one or the other while the output replacement case could be handled by rewarding everything to a miner (essentially all outputs are voided...made unredeemable...and all inputs are added to coinbase) if the miner includes the two conflicting transactions in the same block. Wouldn't this essentially solve the problem? - Eric Lombrozo On Feb 21, 2015 8:09 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote: On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote: This isn't some theoretical exercise. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus scorched earth And maybe by maintaining first seen policies we're harming the system in the long term by encouraging people to widely deploy systems based on extremely weak assumptions. Lacking a coded, reviewed alternative, that's only a platitude. Widely used 0-conf payments are where we're at today. Simply ceasing the maintaining [of] first seen policies alone is simply not a realistic option. The negative impact to today's userbase would be huge. Instant payments need a security upgrade, yes. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
It seems to me we're confusing two completely different motivations for double-spending. One is the ability to replace a fee, the other is the ability to replace outputs. If the double-spend were to merely add or remove inputs (but keep at least one input in common, of course), it seems fairly safe to assume it's the former, a genuine fee replacement. Even allowing for things like coinjoin, none of the payees would really care either way. Conversely, if at least one of the inputs were kept but none of the outputs were, we can be confident it's the the latter. It is possible to build a wallet that always does the former when doing fee replacement by using another transaction to create an output with exactly the additional desired fee. If we can clearly distinguish these two cases then the fee replacement case can be handled by relaying both and letting miners pick one or the other while the output replacement case could be handled by rewarding everything to a miner (essentially all outputs are voided...made unredeemable...and all inputs are added to coinbase) if the miner includes the two conflicting transactions in the same block. Wouldn't this essentially solve the problem? - Eric Lombrozo On Feb 21, 2015 8:09 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote: On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote: This isn't some theoretical exercise. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus scorched earth And maybe by maintaining first seen policies we're harming the system in the long term by encouraging people to widely deploy systems based on extremely weak assumptions. Lacking a coded, reviewed alternative, that's only a platitude. Widely used 0-conf payments are where we're at today. Simply ceasing the maintaining [of] first seen policies alone is simply not a realistic option. The negative impact to today's userbase would be huge. Instant payments need a security upgrade, yes. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Sunday, February 22, 2015, Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo elombr...@gmail.com javascript:; wrote: In case it wasn't clear in my earlier post, there's of course a third possibility - namely, some outputs are kept but not all. Here, it is generally impossible to tell whether the motivation was fee replacement, output replacement, or both. My proposal is to always treat these instances as output replacement and punish the sender. The sender needs to make it unambiguously clear it's only a fee replacement by creating a new transaction that produces an output with the desired extra fee and then adding an input that spends it to the original transaction. That's a really old idea - I proposed it about two years ago. The optimal way is to allow any txout to be replaced with one with an equal or greater nValue and same scriptPubKey, as well as additional txouts added. (obviously so long as none are removed) That won't work because in general it is impossible to know which transaction is the original. Did we add outputs to transaction A? Or remove outputs from transaction B? Alas, there's lots of situations where this restricts you from doing useful things, for instance collapsing multiple payments into one by repeated updating to reduce tx size. Equally the benefit is marginal at best given how insecure unconfirmed transactions are - breaking what is already broken isn't a negative. I think you're unnecessarily complicating use cases. As for 0-conf security, there are instances where 0-conf transactions make a lot of sense - i.e. paying for utilities, ISP, web hosting, or other such services which could be immediately shut off upon detection of a double-spend. -BEGIN PGP SIGNATURE- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6d9O AAoJEMCF8hzn9LncUOUH/3yY4wDyFSkL9o6GsntphAmJSN35wVAlxPxBmNTk0KR3 YfVhY1cTBIXKqsfqz/n1Sqn264aMzW48xUTtDF2xLzJc1FY5qTBw7zbVrZgYIvvr GEakZW1SxLXsfSs2Onutl0WQWi8EMfxEXEPQIiiWy9mq4EtwxMOcDviETycu6Wmn pmHY00Lo8jhLUyuIkzIZrZetEtWz1VtovbJO5l7WfmLgPWzW+zERPY/pGGioqdiJ NOEaocQ+2+OZjyx3MJ4YAch5ZtfB45g+NBm8WyeGpBgxzK3ZIpmyZIQ6HqZr0gpl NMUQh6Sbi8WaTEp6hoYTiEfZcEy4IDPg6f0DEW71BPs= =1vbN -END PGP SIGNATURE- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
I don’t really have a strong opinion on block size either…but if we’re going to do a hard fork, let’s use this as an opportunity to create a good process for hard forks (which we’ll inevitably need to do again in the future). The change in block size is a very simple change that still allows us to explore all the complexities involved with deployment of hard forks. Let’s not just do a one-off ad-hoc thing. - Eric Lombrozo On May 6, 2015, at 3:30 PM, slush sl...@centrum.cz wrote: I don't have strong opinion @ block size topic. But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE (https://bitcointalk.org/index.php?topic=181734.0 https://bitcointalk.org/index.php?topic=181734.0) or its alternative. All developers of lightweight (blockchain-less) clients will adore you! slush On Thu, May 7, 2015 at 12:12 AM, Matt Corallo bitcoin-l...@bluematt.me mailto:bitcoin-l...@bluematt.me wrote: Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in several years as far as I can tell. Block size is a question to which there is no answer, but which certainly has a LOT of technical tradeoffs to consider. I know a lot of people here have varying levels of strong or very strong opinions about this, and the fact that it is not being discussed in a technical community publicly anywhere is rather disappointing. So, at the risk of starting a flamewar, I'll provide a little bait to get some responses and hope the discussion opens up into an honest comparison of the tradeoffs here. Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase. Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. What we see today are transactions enjoying next-block confirmations with nearly zero pressure to include any fee at all (though many do because it makes wallet code simpler). This allows the well-funded Bitcoin ecosystem to continue building systems which rely on transactions moving quickly into blocks while pretending these systems scale. Thus, instead of working on technologies which bring Bitcoin's trustlessness to systems which scale beyond a blockchain's necessarily slow and (compared to updating numbers in a database) expensive settlement, the ecosystem as a whole continues to focus on building centralized platforms and advocate for changes to Bitcoin which allow them to maintain the status quo[1]. Matt [1] https://twitter.com/coinbase/status/595741967759335426 https://twitter.com/coinbase/status/595741967759335426 -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https
Re: [Bitcoin-development] Block Size Increase
On May 7, 2015, at 4:20 AM, Wladimir J. van der Laan laa...@gmail.com wrote: For sake of brevity, this ignores the inherent practical and political issues in scheduling a hardfork. IMHO, these issues are the elephant in the room and the talk of block size increases is just a distraction. - Eric Lombrozo signature.asc Description: Message signed with OpenPGP using GPGMail -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
It all comes down to managing risk. If you’ve got a decent risk model with capped losses and safe recovery mechanisms…and it’s still profitable…it’s fine. But most payment processors and merchants right now probably don’t have particularly good risk models and are making many dangerous assumptions…and probably would not be able to gracefully handle very many risk scenarios. - Eric Lombrozo On Jun 19, 2015, at 6:23 PM, Aaron Voisine vois...@gmail.com wrote: What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe. They don't need to be made cryptographically safe, they just have to be safer than, for instance, credit card payments that can be charged back. As long as it's reasonably good in practice, that's fine. Aaron Voisine co-founder and CEO breadwallet.com http://breadwallet.com/ On Fri, Jun 19, 2015 at 6:09 PM, Mark Friedenbach m...@friedenbach.org mailto:m...@friedenbach.org wrote: What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe. On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson andr...@petersson.at mailto:andr...@petersson.at wrote: I have some experience here. If you are seriously suggesting these measures, you might as well kill retail transactions altogether. In practice, if a retail place starts to accept bitcoin they have a similar situation as with cash, only that the fraud potential is much lower. (e.g. 100-dollar bill for a sandwich might turn out fake later) and the fraud frequency is also much lower. 0-conf concerns were never a problem in practice. except for 2-way atms i have never heard of a problem that was caused by double spends. while adding these measures is generally positive, requiring them means excluding 99.9% of the potential users. so you might as well not do it. RBF as implemented by F2Pool just flat out lowers Bitcoins utility value. So it's a bad thing. for any online or automated system, waiting for a handful of confirmations was always recommended practice. Am 19.06.2015 um 22:39 schrieb Matt Whitlock: Retail POS merchants probably should not be accepting vanilla Bitcoin payments, as Bitcoin alone does not (and cannot) guarantee the irreversibility of a transaction until it has been buried several blocks deep in the chain. Retail merchants should be requiring a co-signature from a mutually trusted co-signer that vows never to sign a double-spend. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
I don’t think the issue is between larger blocks on the one hand and things like lightning on the other - these two ideas are quite orthogonal. Larger blocks aren’t really about addressing basic scalability concerns - for that we’ll clearly need architectural and algorithmic improvements…and will likely need to move to a model where it isn’t necessary for everyone to validate everyone else’s latte purchases. Larger blocks might, at best, keep the current system chugging along temporarily - although I’m not sure that’s necessarily such a great thing…we need to create a fee market sooner or later, and until we do this, block size issues will continue to crop up again and again and economic incentives will continue to be misplaced. It would be nice to have more time to really develop a good infrastructure for this…but without real market pressures, I’m not sure it will happen at all. Necessity is the mother of invention, after all. The question is how to introduce a fee market smoothly and with the overwhelming consensus of the community - and that's where it starts to get tricky. —— On a separate note, as several others have pointed out in this thread (but I wanted to add my voice to this as well), maintenance of source code repositories is NOT the real issue here. The bitcoin/bitcoin project on github is a reference implementation of the Satoshi protocol…but it is NOT the only implementation…and it wasn’t really meant to be. Anyone is free to fork it, extend it, improve upon it, or create an entirely new network with its own genesis block…a separate cryptoledger. The real issue regarding XT is NOT the forking of source code nor issues surrounding commit access to repositories. The real issue is the *forking of a cryptoledger*. Open source repositories are meant to be forked - in fact, it is often encouraged. It is also encouraged that improvements be submitted for review and possibly merged back into the parent repository…although this doesn’t always happen. However, we currently have no mechanisms in place to support merging of forked cryptoledgers. Software, and most other forms of digital content, generally increases in value with more copies made. However, money is scarce…by design. The entire value of the assets of a decentralized cryptoledger rests on the assumption that nobody can just unilaterally fork it and change the rules. Yes, convincing other people to do things a certain way is HARD…yes, it can be frustratingly slow…I’ve tried to push for many changes to the Bitcoin network…and have only succeeded a very small number of times. And yes, it’s often been quite frustrating. But trying to unilaterally impose a change of consensus rules for an existing cryptoledger sets a horrendous precedent…this isn’t just about things like block size limits, which is a relatively petty issue by comparison. It would be very nice to have a similar workflow with consensus rule evolution as we do with most other open source projects. You create a fork, demonstrate that your ideas are sound by implementing them and giving others something that works so they can review them, and then merge your contributions back in. However, the way Bitcoin is currently designed, this is unfortunately impossible to do this with consensus rules. Once a fork, always a fork - a.k.a. altcoins. Say what you will about how most altcoins are crap - at least most of them have the decency of starting with a clean ledger. - Eric Lombrozo On Jun 18, 2015, at 5:57 PM, Chris Pacia ctpa...@gmail.com wrote: On 06/18/2015 06:33 PM, Mark Friedenbach wrote: * Get safe forms of replace-by-fee and child-pays-for-parent finished and in 0.12. * Develop cross-platform libraries for managing micropayment channels, and get wallet authors to adopt * Use fidelity bonds, solvency proofs, and other tricks to minimize the risk of already deployed off-chain solutions as an interim measure until: * Deploy soft-fork changes for truly scalable solutions like Lightning Network. One of my biggest concerns is that these solutions (lightning network in particular) could end up being worse, in terms of decentralization, than would be a bitcoin network using larger blocks. We don't exactly know what the economies of scale are for pay hubs and could very well end up with far fewer hubs than nodes at any conceivable block size. Of course, it could also turn out to be fantastic, but it seems like an enormous gamble to basically force everyone in the ecosystem to collectively spend millions of dollars upgrading to Lightning and then see whether it's actually an improvement in terms of decentralization. To me, a much more sane approach would be to allow people to voluntarily opt in to those other solutions after we've had an opportunity to experiment with them and see how they actually function in practice, but that can't happen if the network runs out of capacity first
Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
IPv4 came before IPv6…you pick up on things quickly :) On Jun 19, 2015, at 5:48 AM, Marcel Jamin mar...@jamin.net wrote: At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! came before Google…MySpace came before Facebook… And TCP/IP came before... oh wait... 2015-06-19 14:02 GMT+02:00 Eric Lombrozo elombr...@gmail.com mailto:elombr...@gmail.com: On Jun 19, 2015, at 3:45 AM, Dr Adam Back a...@cypherspace.org mailto:a...@cypherspace.org wrote: That wont be good for the companies either, but they may not see that until they've killed it, many companies operate on a1 or 2 year time-horizon. They may say screw layer2, I have a runway and I need micropayments to the wazoo and I dont have the dev resources for that. Exactly, Adam. Except, I think the genie is out of the bottle - these ideas are too powerful for them to be killed forever. They will probably survive even if this scenario comes to pass…but in a different network under a different name…and Bitcoin will be relegated to the history books and walls of museums. Most of the potential brainpower available on this Earth to make serious, profound contributions to this movement haven’t even begun to touch it. Just because you happen to run a Bitcoin startup right now…even if you’ve received millions of dollars in funding…don’t think that the whole world has low standards and is lazy! Someone WILL eventually build something better than we can presently imagine. First mover advantage and the network effect are vastly overrated. At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! came before Google…MySpace came before Facebook…Bitcoin came before we don’t know yet. - Eric Lombrozo -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Jun 19, 2015, at 3:45 AM, Dr Adam Back a...@cypherspace.org mailto:a...@cypherspace.org wrote: That wont be good for the companies either, but they may not see that until they've killed it, many companies operate on a1 or 2 year time-horizon. They may say screw layer2, I have a runway and I need micropayments to the wazoo and I dont have the dev resources for that. Exactly, Adam. Except, I think the genie is out of the bottle - these ideas are too powerful for them to be killed forever. They will probably survive even if this scenario comes to pass…but in a different network under a different name…and Bitcoin will be relegated to the history books and walls of museums. Most of the potential brainpower available on this Earth to make serious, profound contributions to this movement haven’t even begun to touch it. Just because you happen to run a Bitcoin startup right now…even if you’ve received millions of dollars in funding…don’t think that the whole world has low standards and is lazy! Someone WILL eventually build something better than we can presently imagine. First mover advantage and the network effect are vastly overrated. At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! came before Google…MySpace came before Facebook…Bitcoin came before we don’t know yet. - Eric Lombrozo signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
OK, a few things here: The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…and relaxing this assumption without adequately assessing the risk (i.e. I’ve never been hacked before so I can assume it’s safe) is extremely dangerous at best and just horrid security practice at worst. Your users might not thank you for not getting hacked - but they surely will not like it when you DO get hacked…and lack a proper recovery plan. Furthermore, the protocol itself makes no assumptions regarding the intentions behind someone signing two conflicting transactions. There are many potential use cases where doing so could make a lot of sense. Had the protocol been designed along the lines of, say, tendermint…where signing multiple conflicting blocks results in loss of one’s funds…then the protocol itself disincentivizes the behavior without requiring any sort of altruistic, moralistic assumptions. That would also mean we’d need a different mechanism for the use cases that things like RBF address. Thirdly, taken to the extreme, the viewpoint of “signing a conflicting transaction is fraud and vandalism” means that if for whatever reason you attempt to propagate a transaction and nobody mines it for a very long time, you’re not entitled to immediately reclaim those funds…they must remain in limbo forever. - Eric Lombrozo On Jun 19, 2015, at 8:11 AM, Peter Todd p...@petertodd.org wrote: On Fri, Jun 19, 2015 at 03:00:57PM +, justusranv...@riseup.net wrote: On 2015-06-19 10:39, Peter Todd wrote: Yesterday F2Pool, currently the largest pool with 21% of the hashing power, enabled full replace-by-fee (RBF) support after discussions with me. This means that transactions that F2Pool has will be replaced if a conflicting transaction pays a higher fee. There are no requirements for the replacement transaction to pay addresses that were paid by the previous transaction. Intentional fraud is a bad thing to add to a financial protocol. A user who creates conflicting transactions, one that pays someone else and another which does not pay them, and broadcasts both of them, has just self-incriminated themselves by producing prima facie evidence of fraud. Depends. If you ask me to pay you 1BTC at address A and I create tx1 that pays 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2 that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not defrauding you, I'm just reducing the value of my change address to pay a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C. Yet from the point of view of an external observer they have no idea why the transaction outputs reduced in size, nor any way of knowing if fraud did or did not occur. Equally, maybe you tell me Actually, just give me 0.5BTC to cancel out that debt, in which case I'm not breaking any contract at all by giving you less money than I first promised - the contract has changed. Again, none of this can or should be observable to anyone other than the parties directly involved. It may be the case that since Bitcoin spans multiple legal jurisdictions and can be use anonymously that the victims of such fraud can not rely on legal recourse, and it may also be the case that proof of work is how Bitcoin deals with the aforementioned factors, but regardless un-prosecutable fraud is still fraud and anyone who encourages it should be recognied as a bad actors. Committing vandalism and encouraging fraud to prove a point may be something the network can't stop on a technical level, but there's no reason not to call it out for what it is. What do you think of Bitcoin XT then? It relays double-spends, which makes it much easier to get double-spends to miners than before. In particular you see a lot of zero-fee transactions being replaced by fee-paying transactions, relayed through Bitcoin XT nodes and then mined. Is that encouraging fraud? -- 'peter'[:-1]@petertodd.org 03932458055c68d4ee2b6d68441c4764efbdf6b0b1683717 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay… On Jun 19, 2015, at 9:36 AM, Matt Whitlock b...@mattwhitlock.name wrote: On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote: I'd also like to note that prima facie doesn't mean always, it means that the default assumption, unless proven otherwise. Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend. signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
On Jun 20, 2015, at 4:37 PM, justusranv...@riseup.net wrote: Signed PGP part On 2015-06-20 18:20, Jorge Timón wrote: On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo elombr...@gmail.com wrote: If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay… Non-repudiation can be built on top of the payment protocol layer. Non-repudiation is an intrinsic property of the ECDSA signatures which Bitcoin uses - it's not a feature that needs to be built. There's no way to accidentally sign a transaction and accidentally announce it publicly. There is no form of third-party error that can result in a payee receiving an erroneous contract. Justus, We don’t even have a concept of identity in the Bitcoin protocol, let alone non-repudiation. What good is non-repudiation if there’s no way to even associate a signature with a legal entity? Sure, we could use the ECDSA signatures in transactions as part of a non-repudiation scheme - but the recipient would have to also have a means to establish the identity of the sender and associate it with the the transaction. Furthermore, in light of the fact that there *are* fully legitimate use cases for sending conflicting transactions…and the fact that determination of intent isn’t always entirely clear…we should refrain from attaching any further significance transaction signatures other than that “the sender was willing to have it included in the blockchain if a miner were to have seen it and accepted it…but perhaps the sender would have changed their mind before it actually did get accepted.” - Eric Lombrozo signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
On Jun 20, 2015, at 5:27 PM, justusranv...@riseup.net wrote: Signed PGP part On 2015-06-20 19:19, Eric Lombrozo wrote: On Jun 20, 2015, at 4:37 PM, justusranv...@riseup.net wrote: Signed PGP part On 2015-06-20 18:20, Jorge Timón wrote: On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo elombr...@gmail.com wrote: If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay… Non-repudiation can be built on top of the payment protocol layer. Non-repudiation is an intrinsic property of the ECDSA signatures which Bitcoin uses - it's not a feature that needs to be built. There's no way to accidentally sign a transaction and accidentally announce it publicly. There is no form of third-party error that can result in a payee receiving an erroneous contract. Justus, We don’t even have a concept of identity in the Bitcoin protocol, let alone non-repudiation. What good is non-repudiation if there’s no way to even associate a signature with a legal entity? Sure, we could use the ECDSA signatures in transactions as part of a non-repudiation scheme - but the recipient would have to also have a means to establish the identity of the sender and associate it with the the transaction. Furthermore, in light of the fact that there *are* fully legitimate use cases for sending conflicting transactions…and the fact that determination of intent isn’t always entirely clear…we should refrain from attaching any further significance transaction signatures other than that “the sender was willing to have it included in the blockchain if a miner were to have seen it and accepted it…but perhaps the sender would have changed their mind before it actually did get accepted.” Bitcoin has no concept of identity, but in any type of commercial transaction the parties involved must know some minimal amount of identity information in order to transact at all. Except for some identifiable special cases, I think a payee is perfectly justified in treating a double spend of a payment sent to them as part of a commercial transaction as a fraud attempt and employing whatever non-Bitcoin recourse mechanisms, if any, they have access to. From the perspective of the network, the obviously correct action for any node or miner is to relay the first version of any transaction they see. The primary purpose of mining is to resolve this otherwise-unresolvable problem of determining which transaction among a set of conflicting transactions happened first. If a node or miner wants to deviate from the obviously correct behaviour, and if they want to avoid harming the value of the network, they should be particularly careful to make sure their deviation from first seen doesn't introduce harmful unintended side effects, like making fraud easier. The contract between the buyer and seller is actually outside the Bitcoin network. Yes, a merchant that gets cheated could seek some other recourse in such an event…but the behavior you’re claiming as “obviously correct” is NOT obviously correct. In fact, there are arguments against this “obviously correct” way even if we were to accept the premise that the signature implies a promise to pay (which I think many reasonable individuals would also dispute). For instance, by relaying conflicting transactions it makes it potentially easier for others to discover the double-spend attempt (of course, this requires wallets to not be lazy about this…perhaps such relays could be flagged or placed in a special message type). - Eric Lombrozo signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
On Jun 20, 2015, at 4:47 PM, Eric Lombrozo elombr...@gmail.com wrote: On Jun 20, 2015, at 4:16 PM, Jorge Timón jti...@jtimon.cc wrote: On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo elombr...@gmail.com wrote: The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time… I disagree with this premise. Please, don't take this as an argument from authority fallacy, but I will cite Satoshi to express what I think the assumptions while using the system should be: As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. I can't say for sure what was meant by attacking the network in this context but I personally mean trying to rewrite valid and proof-of-work-timestamped history. Unconfirmed transactions are simply not part of history yet. Ordering unconfirmed transactions in a consensus compatible way without a universal clock is impossible, that's why we're using proof of work in the first place. Alternative policies are NOT attacks on the network. Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions are part of any sort of global consensus. In fact, they very much AREN’T. Which is exactly why it is extremely dangerous to accept unconfirmed transactions as final unless you clearly have assessed the risks and it makes sense for the particular business use case. - Eric Lombrozo I think the misunderstanding was in perhaps my earlier statement seemed like I was suggesting that it’s the protocol’s responsibility to protect merchants from double-spends. On the contrary - I think we agree - the protocol CANNOT make any guarantees to ANYONE until we do converge on a history. The “design” I speak of here is more on the merchant side. - Eric Lombrozo signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] comments on BIP 100
OK. O() notation normally refers to computational complexity, but ... I still don't get it - the vast majority of users don't run relaying nodes that take part in gossiping. They run web or SPV wallets. And the nodes that do take part don't connect to every other node. It's a little scary, IMO, that the fact that the majority of nodes don't relay and only perform the most rudimtentary level of validation if any is considered an acceptable feature of the protocol. - Eric Lombrozo -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
I definitely think we need some voting system for metaconsensus…but if we’re going to seriously consider this we should look at the problem much more generally. Using false choices doesn’t really help, though ;) - Eric Lombrozo On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote: On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com mailto:elombr...@gmail.com wrote: 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. What is the alternative? Have a Chief Scientist or Technical Advisory Board choose what is a proper fee, what is a proper level of decentralization, a proper growth factor? signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
Chun, With all due respect, there are a couple major differences between BIP34 and BIP66 on the one hand and BIP100 on the other. 1) BIP34 and BIP66 are soft forks. Miners choosing to switch to them will not seriously impact validation rules for non-mining users that do not make the switch. With BIP66, the worst that can happen to them is noncompliant transactions will no longer be accepted by the network…but even nodes that do not switch over will continue to remain synched with the network. 2) BIP100 has direct economic consequences…and particularly for miners. It lends itself to much greater corruptibility. - Eric Lombrozo On Jun 13, 2015, at 9:55 PM, Chun Wang 1240...@gmail.com wrote: To tell you the truth. It is only because most miners are not located in the West. If Slush, Eligius and BTC Guild still on top 3, the core developers, including brain-dead Mike Hearn, would be very happy to do BIP100 just like they did BIP34 and BIP66. Shame on you! On Sun, Jun 14, 2015 at 6:20 AM, Danny Thorpe danny.tho...@gmail.com wrote: Please forgive my ignorance, but why should Bitcoin users have a say in block size limits? It's the miners and Bitcoin node operators that bear the burden of managing large blocks, no? Users voting on network parameters sounds like neighbors voting on how deep my swimming pool should be. Thanks, -Danny On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd p...@petertodd.org wrote: Jeff Garzik recently proposed that the upper blocksize limit be removed entirely, with a soft limit being enforced via miner vote, recorded by hashing power. This mechanism within the protocol for users to have any influence over the miner vote. We can add that back by providing a way for transactions themselves to set a flag determining whether or not they can be included in a block casting a specific vote. We can simplify Garzik's vote to say that one of the nVersion bits either votes for the blocksize to be increased, or decreased, by some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a nVersion bit in transactions themselves, also voting for an increase or decrease. Transactions may only be included in blocks with an indentical vote, thus providing miners with a monetary incentive via fees to vote according to user wishes. Of course, to cast a don't care vote we can either define an additional bit, or sign the transaction with both versions. Equally we can even have different versions with different fees, broadcast via a mechanism such as replace-by-fee. See also John Dillon's proposal for proof-of-stake blocksize voting: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork
On Jun 15, 2015, at 3:54 PM, odinn odinn.cyberguerri...@riseup.net wrote: I also disagree with the notion that everybody's just ok with what Mike and Gavin are doing specifically, this statement by Mike The consensus you seek does exist. All wallet developers (except Lawrence), all the major exchanges, all the major payment processors and many of the major mining pools want to see the limit lifted This is certainly twisting words! We all agree that the limit needs to eventually be lifted - but some of us certainly disagree with the means being used to do so by Mike and Gavin. Most news publications keep the discussion rather shallow and like to keep the controversy pretty black and white - some of us have far more nuanced views! - Eric Lombrozo signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] User vote in blocksize through fees
That’s exactly the problem with Bitcoin - it was supposed to be the case that users ARE the miners and node operators…but…alas… On Jun 13, 2015, at 3:20 PM, Danny Thorpe danny.tho...@gmail.com wrote: Please forgive my ignorance, but why should Bitcoin users have a say in block size limits? It's the miners and Bitcoin node operators that bear the burden of managing large blocks, no? Users voting on network parameters sounds like neighbors voting on how deep my swimming pool should be. Thanks, -Danny On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd p...@petertodd.org mailto:p...@petertodd.org wrote: Jeff Garzik recently proposed that the upper blocksize limit be removed entirely, with a soft limit being enforced via miner vote, recorded by hashing power. This mechanism within the protocol for users to have any influence over the miner vote. We can add that back by providing a way for transactions themselves to set a flag determining whether or not they can be included in a block casting a specific vote. We can simplify Garzik's vote to say that one of the nVersion bits either votes for the blocksize to be increased, or decreased, by some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a nVersion bit in transactions themselves, also voting for an increase or decrease. Transactions may only be included in blocks with an indentical vote, thus providing miners with a monetary incentive via fees to vote according to user wishes. Of course, to cast a don't care vote we can either define an additional bit, or sign the transaction with both versions. Equally we can even have different versions with different fees, broadcast via a mechanism such as replace-by-fee. See also John Dillon's proposal for proof-of-stake blocksize voting: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org http://petertodd.org/ 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses
A few months back, William Swanson and I had worked on a more general script template format. Unfortunately, other work has prevented us from being able to fully complete it - but here’s the start: https://docs.google.com/document/d/1nGF6LjGwhzuiJ9AQwKAhN1a1SXvGGHWxoKmDSkiIsPI https://docs.google.com/document/d/1nGF6LjGwhzuiJ9AQwKAhN1a1SXvGGHWxoKmDSkiIsPI/ - Eric Lombrozo On Feb 12, 2015, at 11:53 PM, Peter Todd p...@petertodd.org wrote: On Thu, Feb 12, 2015 at 10:13:33PM +, Luke Dashjr wrote: Where is the Specification section?? Does this support arbitrary scripts, or only the simplest CHECKMULTISIG case? It might be enough to rewrite this BIP to basically say all pubkeys executed by all CHECKMULTISIG opcodes will be in the following canonical order, followed by some explanatory examples of how to apply this simple rule. OTOH we don't yet have a standard way of even talking about arbitrary scripts, so it may very well turn out to be the case that the above rule is too restrictive in many cases - I certainly would not want to do a soft-fork to enforce this, or even make it an IsStandard() rule. -- 'peter'[:-1]@petertodd.org 13cf8270118ba2efce8b304f8de359599fef95c3ab43dcb1 -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development signature.asc Description: Message signed with OpenPGP using GPGMail -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
