Re: [Bitcoin-development] BIP32 Index Randomisation
Could you describe what exactly BWS does? Sure. BWS tasks are: * Coordinate Transaction proposals in multisignature wallets: provide an 'always connected' node to distribute pending transaction proposals and receive the signatures from peers. * Coordinate and store BIP32 derivation indexes. (If the BWS disappear, peer can still access the funds by scanning the blockchain, but having the index in a common accessable point in useful). * Access the blockchain and provide functions like: `getBalance` and `getTxHistory` to peers. * Allow agents to notify incoming funds / or transaction proposals to peers. BWS is designed to be extremely easy to setup and run. BitPay will provide a public BWS instance, but companies and individuals can run their own for privacy and security reasons. It sounds like the server doesn't have to actually derive the keys itself for any particular purpose beyond knowing the addresses are a part of the wallet. Could the server work if it didn't even know that, and was just a bucket of arbitrary addresses with the clients themselves deriving the addresses? We have evaluated BWS not having the extended public keys (and it is still an open possibility) but the main drawback we found is that BWS will have no way to verify addresses sent by the peers (*). A peer could send a fake address to BWS and then functions like 'getBalance' or 'txHistory' will be broken. Of course, the peers could verify the addresses on getTxHistory or getBalance (by Address) but we also want to allow thin-clients and agents with lower level of trust (than the server) that can notify the wallet balance and incoming transaction to peers using, for example, mobile push notifications. (*): Gregory Maxwell proposed an schema for doing this with the not extended pubkeys, that we need to evaluate. That could be the best solution. -- 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
Re: [Bitcoin-development] BIP32 Index Randomisation
It sounds like the main issue is this is a web wallet server of some kind. If the clients were SPV then they'd be checking their own balances and downloading their own tx history, which would mean the coordination tasks could be done by storing encrypted blobs on the server rather than the server itself having insight into what's going on (see: Subspace). So whilst you might be able to use some scheme to avoid the server knowing the xpubkey, if the server still knows all addresses and all transactions because the clients are web wallets . is there any point? It seems like maybe going from server knows everything to server knows 95% of everything: maybe not worth the engineering cost. -- 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
Re: [Bitcoin-development] Proof of Payment
As soon as that PaymentRequest leaves the wallet on its way to the hotel server, it is up for grabs Is it? I'm assuming TLS is being used here. And the hotel server also has a copy of the PaymentRequest, as the hotel actually issued it and that's how they're deciding the receipt is valid. So I don't know how it could be stolen unless the attacker can break TLS. -- 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
Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/13/2015 04:48 PM, Mike Hearn wrote: That would be rather new and tricky legal territory. But even putting the legal issues to one side, there are definitional issues. For instance if the Chainalysis nodes started following the protocol specs better and became just regular nodes that happen to keep logs, would that still be a violation? If so, what about blockchain.info? It'd be shooting ourselves in the foot to try and forbid block explorers given how useful they are. I'm not talking about keeping logs, I mean purporting to be a network peer in order to gain a connection slot and then not behaving as one (not relaying transactions), thereby depriving the peers to which operator actually intends to offer service of the ability to connect. That someone wants to run a large number of nodes in order to make their own logs more saleable, does not mean they are entitled to break the protocol to make other node operators subsidize their log collection. Especially if a data collection company is deploying nodes that do not relay and aggressively reconnect after a ban, it seems like they'd have a hard time arguing that they were not knowingly exceeding authorized access. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVA16sAAoJECpf2nDq2eYjxsUP/3ASGcsdGR8IEO7Fk8VghuVp jwIIM8Bu/WsoWKG76GhuPKs/qC0VC6GXKpGUBVy7bF8uwdhfdSXcyld9MIzIENJF I0wMX6B3SjqQG/g0rNZ91Dh3xKIF39/TQdDERM3yiQi1oavAc5TPLReN9ZbyRcVw vCfPWorTvrad5INCn/krcEopbI013aW2ryWnkN6sFGinF5Yf4xhrNQbQeGbhlH15 /XUIBva6/PbUs4HaC+wqJPSUfB4OmcP1ZfXMuPDEmKEWdI+3WqUYF4sNAVOke560 +RL5qMJIxSUMYMAb3p+025Fn6WOc2wupQzpH/ISkuaI+5+ne54Mx/ZHJg7Z7inov WMKfiUS6R8EHrY8IoNpO9uNqsgC+y0vlU3ELqu+gOhFTpMK7pVX2aAek8Qe7hSHy GwtG5U6AFubLqyzP9/pBJHnmDG71brsKffAXOePDjXWfLfhy78aeQ3HOnzVhv9QK snmE2C6Ex/tQDUwT9MKTdw59Hy7E7GdQlSPH+MYQKUBlkpWLDGpi7oriBRwvEy4/ NJCJU9+x7jijD7vrjBE+LSYdIQoZqE240N6teWqVc2wRPM8g+e+kSQqfjdKQdiQY waeKHBKerqRq2EGffeJWV1RIEFtFND1l8zw/5ZQF4w959zLvhk/QPHzxKyTbCM2f 3DOgEWCJFLsNzpPQ8es2 =MV9D -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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
[Bitcoin-development] Criminal complaints against network disruption as a service startups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Given the recent news about Chainanalysis (https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/), and other companies who are disrupting the Bitcoin network (https://www.reddit.com/r/Bitcoin/comments/2we0d9/in_an_unrelated_thread_a_bitcoin_dev_claimed/copzt3x) it might be worth reviewing the terms of the Computer Fraud and Abuse Act and similar legislation in other countries. Although it's not possible to stop network attacks by making them illegal, it's certainly possible to stop traditionally funded companies from engaging in that activity. Note there exist no VC-funded DDoS as a service companies operating openly. It's also worth discussing ways to make the responsibilities of network peers more explicit in the protocol, so that when an entity decides to access the network for purposes other than for what full node operators made connection slots available that behavior will be a more obvious violation of various anti-hacking laws. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVA0IFAAoJECpf2nDq2eYjp0IP+wVsW69xOpFIX4yRTHrEQYh7 MCPM7OTkIay/O13TSewbxTRPww9Z6vOpmrDkFlWGYKyrLWyqUGwcKqOscE8r3P3U xdV5ACppol5HXra/bykxuaXJWF/yTM7PybFNQ2Ary0X41CFrOUITsO8SwWDl8jBu GtRgbWdALA6IQeeRLVQmMo3zC/uShOplOh/HrS2z9ZtXSm3rNkLzhnUWfznbixb0 9C1yvIM5VOwoNcRKt7uoX6cl4mFsBO3Gfjz4rr5gABerTltBlRk4c3jnUDUlQiFC cppX9eaEYMLR7y0gHWnmzWcFW7LFwMR2isyJ79O2cpUpYNzbfp0fWetM1WVAMFSK 7hyUlwVx4WgaVRT5hDb6QPHHvzCYjYq+19+9/uChh9P3s3QkKuFJUVYwHQ+wnruK hPS3/vb7Tmt1eLTUeno4RRyJJ7likHsNA2bxWSG9rDezTownkSVZe2BQh3GIZOBg H8Nu2IDWK4pHJaCiswW4jfDsucuYiP7978p8ZFbZbymeflsXz1qyUHSVm9kngfZn sYUK4rgRsdrPpong0nqlmWcQW3VgmNO1tw5gmUqWTxQLnrCxgqnSdT7srzAw1ZaS YIAaB1rBy8k7QyDCOyIsIV+n1H26ZBa8PrqdRExlz6PuWcywjuEbcIfEl9QSURA+ pLuNJ+uQN+JBjKokmaSQ =ZO1/ -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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
[Bitcoin-development] Proof of Payment
Hi all, I've been thinking about how a person can prove that she has made a payment. I came up with an idea I call Proof of Payment (PoP) and I would highly appreciate your comments. Has something like this been discussed somewhere before? *Use cases* There are several scenarios in which it would be useful to prove that you have paid for something. For example: - A pre-paid hotel room where your PoP functions as a key to the door. - An online video rental service where you pay for a video and watch it on any device. - An ad-sign where you pay in advance for e.g. 2-weeks exclusivity. During this period you can upload new content to the sign whenever you like using PoP. - A lottery where all participants pay to the same address, and the winner of the T-shirt is selected among the transactions to that address. You exchange the T-shirt for a PoP for the winning transaction. These use cases can be achieved without any personal information (no accounts, no e-mails, etc) being involved. Desirable properties: 1. A PoP should be generated on demand. 2. It should only be usable once to avoid issues due to theft. 3. It should be able to create a PoP for any payment, regardless of script type (P2SH, P2PKH, etc.). Current methods of proving a payment, as I know of: - BIP0070, The PaymentRequest together with the transactions fulfilling the payment makes some sort of proof. However, it does not meet 1 or 2 and it obviously only meets 3 if the payment is made through BIP0070. Also, there's no standard way to request/provide the proof. - Signing messages, chosen by the entity that the proof is provided to, with the private keys used to sign the transaction. This could meet 1 and 2 but probably not 3. This is not standardized either. *Proof of Payment, the data structure* A proof of payment for a transaction T, PoP(T), is used to prove that one has ownership of the credentials needed to unlock all the inputs of T. It has the exact same structure as a bitcoin transaction with the same inputs as T and with a single OP_RETURN output: OP_RETURN PoP txid nonce | Field | Size [B] | Description| |---|--|| | PoP | 3| Literal identifying this as a PoP | | txid| 32 | The transaction to Prove | | nonce | 5| Unsigned integer | The PoP is signed using the same signing process that is used for bitcoin transactions. The purpose of the nonce is to make it harder to use a stolen PoP. Once the PoP has reached the destination, that PoP is useless since the destination will generate a new nonce for every PoP. *Proof of Payment, the process* 1. A proof of payment request is sent from the server to the wallet. The request contains: 1. a random nonce 2. a destination where to send the PoP, for example a https URL 3. data hinting the wallet which transaction to create a proof for. For example: - txid, if known by the server - PaymentRequest.PaymentDetails.merchant_data (in case of a BIP0070 payment) - amount - label, message or other information from a BIP0021 URL 2. The wallet identifies the transaction T, if possible. Otherwise asks the user to select among the ones that fit the hints in 1.3. 3. The wallet checks that T is on the blockchain, meaning all the inputs are spent. 4. The wallet creates an unsigned PoP (UPoP) for T, and asks the user to sign it. 5. The user confirms 6. The UPoP(T) is signed by the wallet, creating PoP(T). 7. The PoP is sent to the destination in 1.2. 8. The server receiving the PoP validates it and responds with “valid” or “invalid” 9. The wallet displays the response in some way to the user. Remarks: - The method of transferring the PoP request at step 1 is not very well thought through, but I think we can extend BIP0021 to cater for this. For example read a URI, representing a PoP request, using QR code or NFC. A more advanced approach would be to extend BIP0070. - The nonce must be randomly generated by the server for every new PoP request. *Validating a PoP* The server needs to validate the PoP and reply with “valid” or “invalid”. That process is outlined below: 1. Check the format of the PoP. It must pass normal transaction checks, except for the inputs being already spent. 2. Check the output script. It must conform to the OP_RETURN output format outlined above. 3. Check that the nonce is the same as the one you requested. 4. Check that the txid in the output is the transaction you actually want proof for. If you don’t know what transaction you want proof for, check that the transaction actually pays for the product/service you deliver (in the video rental case, find the transaction among all payments for that specific video). 5.
Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups
That would be rather new and tricky legal territory. But even putting the legal issues to one side, there are definitional issues. For instance if the Chainalysis nodes started following the protocol specs better and became just regular nodes that happen to keep logs, would that still be a violation? If so, what about blockchain.info? It'd be shooting ourselves in the foot to try and forbid block explorers given how useful they are. If someone non-maliciously runs some nodes with debug logging turned on, and makes full system backups every night, and keeps those backups for years, are they in violation of whatever pseudo-law is involved? I think it's a bit early to think about these things right now. Michael Grønager and Jan Møller have been Bitcoin hackers for a long time. I'd be interested to know their thoughts on all of this. -- 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
Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups
I'm not talking about keeping logs, I mean purporting to be a network peer in order to gain a connection slot and then not behaving as one (not relaying transactions) That definition would include all SPV clients? I get what you are trying to do. It just seems extremely tricky. -- 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
Re: [Bitcoin-development] Proof of Payment
Den 13 mar 2015 20:57 skrev Kalle Rosenbaum ka...@rosenbaum.se: Hi all, I've been thinking about how a person can prove that she has made a payment. I came up with an idea I call Proof of Payment (PoP) and I would highly appreciate your comments. Has something like this been discussed somewhere before? Use cases There are several scenarios in which it would be useful to prove that you have paid for something. For example: A pre-paid hotel room where your PoP functions as a key to the door. An online video rental service where you pay for a video and watch it on any device. An ad-sign where you pay in advance for e.g. 2-weeks exclusivity. During this period you can upload new content to the sign whenever you like using PoP. A lottery where all participants pay to the same address, and the winner of the T-shirt is selected among the transactions to that address. You exchange the T-shirt for a PoP for the winning transaction. These use cases can be achieved without any personal information (no accounts, no e-mails, etc) being involved. Desirable properties: A PoP should be generated on demand. It should only be usable once to avoid issues due to theft. It should be able to create a PoP for any payment, regardless of script type (P2SH, P2PKH, etc.). Relevant: https://idemix.wordpress.com/ Anonymous Credentials allows an issuer to declare that you have certain rights. For example, upon paying the service provider could issue you the credentials for using their service up until a certain date. When challenged to prove a statement about what credentials you have, you can prove the fact that you've got the right credentials without revealing anything else. You don't even reveal you're the same person as the last time, if you prove the right to access a VPN multiple times there's no data in it that links the different sessions together. The main difference is that issuance of Anonymous Credentials aren't atomic with the payment transactions, which can open up the risk for certain types of dishonest behavior by the seller. You could however use a proof in court of having paid for the credentials but not getting them issued to you (maybe throw in usage of Factom to log issuance of credentials?). With this construction of using both these methods, you add stronger privacy for the usage of the services while simultaneously keeping a degree of accountability for the payment. The Zerocoin developers also got a paper on a blockchain version, Distributed Anonymous Credentials. -- 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
Re: [Bitcoin-development] Proof of Payment
Hi Kalle, I think you're thinking along the right lines, but I am skeptical that this protocol adds much. A saved payment request is meant to be unique per transaction e.g. because the destination address is unique for that payment (for privacy reasons). Where would you store the signed payment request? Probably in the wallet. You could just extract the metadata that's useful for UI rendering into a separate structure and then encrypt the original full payment request under the wallet key. At least this is how I imagine it would work. So then, if someone can steal a payment request they can probably steal the wallet signing keys too, and thus signing a challenge with the wallet keys doesn't add much. It means the wallet doesn't have to store the PaymentRequest encrypted. But AFAICT that's about all it does. Do you agree with this analysis? -- 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
Re: [Bitcoin-development] BIP32 Index Randomisation
You are killing us Mike! :) We really don't like to think that BWS is a webwallet. Note that private keys are not stored (not even encrypted) at the server. Sure, sorry, by web wallet I meant a blockchain.info/CoPay type setup where the client has the private keys and signs txns, but otherwise relies on the server for learning about the wallet contents. I tend to call wallets where the server has the private key BitBanks but I don't know if anyone else uses this terminology. It might just be a personal quirk of my own ;) we think having some visibility of the wallet by the multisig facilitator will make the user experience much better (e.g: mobile notifications). Fair enough. Yes, push notifications to mobiles in a decentralised way is rather a hard problem. I think what Gregory suggested is then the best approach for you to do what you want. Whether it's worth the additional complexity is something I don't have any feedback on, only you can judge that. -- 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
Re: [Bitcoin-development] Proof of Payment
Hi No I don't agree with the analysis. Yes, the PaymentRequest can be stored with the same security as the private keys are stored. The big difference is that the keys never leave the wallet. As soon as that PaymentRequest leaves the wallet on its way to the hotel server, it is up for grabs which makes it inappropriate for use as a proof of payment other than for resolving disputes and other one-time stuff. /Kalle 2015-03-13 22:31 GMT+01:00 Mike Hearn m...@plan99.net: Hi Kalle, I think you're thinking along the right lines, but I am skeptical that this protocol adds much. A saved payment request is meant to be unique per transaction e.g. because the destination address is unique for that payment (for privacy reasons). Where would you store the signed payment request? Probably in the wallet. You could just extract the metadata that's useful for UI rendering into a separate structure and then encrypt the original full payment request under the wallet key. At least this is how I imagine it would work. So then, if someone can steal a payment request they can probably steal the wallet signing keys too, and thus signing a challenge with the wallet keys doesn't add much. It means the wallet doesn't have to store the PaymentRequest encrypted. But AFAICT that's about all it does. Do you agree with this analysis? -- 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
Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/13/2015 05:08 PM, Mike Hearn wrote: That definition would include all SPV clients? Don't SPV clients announce their intentions by the act of uploading a filter? I get what you are trying to do. It just seems extremely tricky. Certainly the protocol could be designed in a way that provides finer-grained access controls and connection limits, which would make the situation more clear. What I'd actually like to see is for network users to pay for the node resources that they consume, so that anyone who wants to place increased load on the network would compensate node operators for the burden: http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/ Absent that kind of comprehensive solution, problems like this will continue to recur. -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJVA2HLAAoJECpf2nDq2eYjcvYP/iqYBxboMmTPLp9Kx3GlBdR/ IPtCxVoaZQkqrAHlbbED1YHoI7QqaufdPMb9mw8bErFX7E89u4gD93jvx2x+skqW KtqIyc5fHe4MgbtGypvE5GjSiqZZIqn7EYzLGVE5ydmO4SKpfodXIIRuQRkZ1fTG j0ovFc/bmigS7Cvf3gsMT5oW26IcEaH6mAZ/YU5oVEi1LGff8hUTq90uddOCpoqp mIj8MHMdd0yvtihjLwyJPdfT0qTOkbAxHJqwPLoOWzmrN0z1PbU9qcf0aHdDnMlT +jWHqHzSxjwyB1bmUhi6vZKVFfd1moOTI3BBj+Jqjc+xaOmXCcyAtpfzq97VITZw qhAnYM4unsC0A1GH3fQEJPvoOy0kwyNNtI7z5YOrRJtihCpFSbtULqN9DUmxwgKL /0cmOc2SyjgflTiCejazBIJk4Ie+WcV2cbgepdX8USb0tusQs+jn2HMFGUfxywTz riy9Ex8Wftl12LAYXSbMQl7GnADYG9t0HIY3JqPAhAzEdPynXUduveatiQyNc6SH IqXraTgHj6IFFWB7eLjWuIleyxcFC81qTFNUYxEajGDLbCX00emKiR3RUpVZ/wP7 8CXcV4zco1y1+va1eD/7eNhTW/Xuf3+KdqJs2reLq23fLV01HA92sRYbgLIxb0Yz yBsE+PpY06vrHqoVD/4l =Ofbb -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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
Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups
Don't SPV clients announce their intentions by the act of uploading a filter? Well they don't set NODE_NETWORK, so they don't claim to be providing network services. But then I guess the Chainalysis nodes could easily just clear that bit flag too. What I'd actually like to see is for network users to pay for the node resources that they consume It's not quite pay-as-you-go, but I just posted a scheme for funding of network resources using crowdfunding contracts here: https://github.com/bitcoin/bitcoin/issues/5783#issuecomment-79460064 That comment doesn't have any kind of provision for access control, but group signatures could be extended in both directions: the server proves it was a part of the group that was funded by the contract, and the client proves it was in group that funded the contract, but it's done in a (relatively) anonymous way. Then any client can use any node it funded, or at least, buy priority access. But it's rather complicated. I'd hope that nodes can be like email accounts: yes they have a cost but in practice people everyone gets one for free because of random commercial cross-subsidisation, self hosting and other things. -- 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
