From lists at coryfields.com Thu Feb 1 01:14:45 2018 From: lists at coryfields.com (Cory Fields) Date: Wed, 31 Jan 2018 20:14:45 -0500 Subject: [bitcoin-dev] New Bitcoin Core macOS signing key In-Reply-To: <23bf1f30b85d0f23d6c9eab93f1d8e06@nym.zone> References: <20180112085412.GA8088@savin.petertodd.org> <23bf1f30b85d0f23d6c9eab93f1d8e06@nym.zone> Message-ID: A public key was published recently for future macOS releases. Sadly, that key was created the wrong way (iPhone OS instead of macOS), so another had to be generated. The new, working pubkey for Bitcoin Core releases starting with 0.16.0rc1 is included in the message below. That message is signed with the key mentioned in the previous mail. It can be verified with: openssl smime -verify -noverify -in msg.pem Sorry for the noise. -----BEGIN PKCS7----- MIIPbQYJKoZIhvcNAQcCoIIPXjCCD1oCAQExCzAJBgUrDgMCGgUAMIIC5gYJKoZI hvcNAQcBoIIC1wSCAtNBIHB1YmxpYyBrZXkgd2FzIHB1Ymxpc2hlZCByZWNlbnRs eSBmb3IgZnV0dXJlIG1hY09TIHJlbGVhc2VzLg0KDQpTYWRseSwgdGhlIHB1Ymxp c2hlZCBrZXkgd2FzIGNyZWF0ZWQgdGhlIHdyb25nIHdheSAoaVBob25lIE9TIGlu c3RlYWQgb2YgbWFjT1MpLCBzbyBhbm90aGVyIGhhZCB0byBiZSByZXF1ZXN0ZWQu DQoNClRoZSBuZXcsIHdvcmtpbmcgcHVia2V5IGZvciBCaXRjb2luIENvcmUgcmVs ZWFzZXMgc3RhcnRpbmcgd2l0aCAwLjE2LjByYzEgaXM6DQoNCi0tLS0tQkVHSU4g UFVCTElDIEtFWS0tLS0tDQpNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4 QU1JSUJDZ0tDQVFFQXF4aWJEZ2pBT09WVXBTY3pVMnBqDQp0UEVpQ0lZeXl2V21E N2VidGhQbzI5WG9xMUJqYWJGNDlCZ3diNkZFaU1haFN5UTY4ZklMSUhDanJ5SUo4 RUN1DQpROFJWbVF3cGdhKzV0OTZiMEM5emN5WTFhcSsrRzIyMVNqNmFpUmVveXZw cHIrZ2poNmNPbktEc1B0Z2pUcGdiDQovOUhuMmtwYzFmZ000ZkRFMlQ2VXZHVHMw d3d5dWNvL21ya0s1LzEySCtqZUE3QXVNcjBLQTBVSktSS1VOenFhDQo4QjlLalFF ektaRGVVVHRYak9vSmIyNkRQU3hCbXBGd25zWSs2aHBjeFZSSmphNG1FYzRFYnIy b2gxSmVORU5uDQp4WXR3MHRWVWczTUwvWlI2WU9qQVpMY0V0cW5IR2ZOZXVRazJX Vm1pYy9JY3d4VEM0cUk4MnFROGgxQnFpY3pRDQo4UUlEQVFBQg0KLS0tLS1FTkQg UFVCTElDIEtFWS0tLS0tDQqgggnZMIIFzTCCBLWgAwIBAgIId5kUM+xSbWMwDQYJ KoZIhvcNAQELBQAwgZYxCzAJBgNVBAYTAlVTMRMwEQYDVQQKDApBcHBsZSBJbmMu MSwwKgYDVQQLDCNBcHBsZSBXb3JsZHdpZGUgRGV2ZWxvcGVyIFJlbGF0aW9uczFE MEIGA1UEAww7QXBwbGUgV29ybGR3aWRlIERldmVsb3BlciBSZWxhdGlvbnMgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgwMTEwMjAyNTA1WhcNMTkwMTEwMjAy NTA1WjCBwDEaMBgGCgmSJomT8ixkAQEMCllaQzdXSDNNUlUxUDBOBgNVBAMMR2lQ aG9uZSBEaXN0cmlidXRpb246IEJpdGNvaW4gQ29yZSBDb2RlIFNpZ25pbmcgQXNz b2NpYXRpb24gKFlaQzdXSDNNUlUpMRMwEQYDVQQLDApZWkM3V0gzTVJVMS4wLAYD VQQKDCVCaXRjb2luIENvcmUgQ29kZSBTaWduaW5nIEFzc29jaWF0aW9uMQswCQYD VQQGEwJVUzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsYmw4IwDjl VKUnM1NqY7TxIgiGMsr1pg+3m7YT6NvV6KtQY2mxePQYMG+hRIjGoUskOvHyCyBw o68iCfBArkPEVZkMKYGvubfem9Avc3MmNWqvvhtttUo+mokXqMr6aa/oI4enDpyg 7D7YI06YG//R59pKXNX4DOHwxNk+lLxk7NMMMrnKP5q5Cuf9dh/o3gOwLjK9CgNF CSkSlDc6mvAfSo0BMymQ3lE7V4zqCW9ugz0sQZqRcJ7GPuoaXMVUSY2uJhHOBG69 qIdSXjRDZ8WLcNLVVINzC/2UemDowGS3BLapxxnzXrkJNllZonPyHMMUwuKiPNqk PIdQaonM0PECAwEAAaOCAfEwggHtMD8GCCsGAQUFBwEBBDMwMTAvBggrBgEFBQcw AYYjaHR0cDovL29jc3AuYXBwbGUuY29tL29jc3AwMy13d2RyMTEwHQYDVR0OBBYE FNOBKRRpuWarZwT6owhUtiOP6lbSMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU iCcXCam2GGCL7Ou69kdZxVJUo7cwggEdBgNVHSAEggEUMIIBEDCCAQwGCSqGSIb3 Y2QFATCB/jCBwwYIKwYBBQUHAgIwgbYMgbNSZWxpYW5jZSBvbiB0aGlzIGNlcnRp ZmljYXRlIGJ5IGFueSBwYXJ0eSBhc3N1bWVzIGFjY2VwdGFuY2Ugb2YgdGhlIHRo ZW4gYXBwbGljYWJsZSBzdGFuZGFyZCB0ZXJtcyBhbmQgY29uZGl0aW9ucyBvZiB1 c2UsIGNlcnRpZmljYXRlIHBvbGljeSBhbmQgY2VydGlmaWNhdGlvbiBwcmFjdGlj ZSBzdGF0ZW1lbnRzLjA2BggrBgEFBQcCARYqaHR0cDovL3d3dy5hcHBsZS5jb20v Y2VydGlmaWNhdGVhdXRob3JpdHkvMA4GA1UdDwEB/wQEAwIHgDAWBgNVHSUBAf8E DDAKBggrBgEFBQcDAzATBgoqhkiG92NkBgEEAQH/BAIFADANBgkqhkiG9w0BAQsF AAOCAQEARvNgy5mhFqZsI5JGgn6HSR/eQIXjuoGyOivOa6+uCb5qcrSjSR+PSj7D K/SBxrz+sVgKvwQ3buhv3BJnURmbYtEmqRr60G+yZE6xNpDMEyZyEM7aT6R9zBMX ++5mwqq5Ip57Mq8yB+pGTzSCBUAat6qiMBUkJBa+F/fk+vXZxgKAfKGMEfALLR5j Rnwadg2CoTng47Mt4gzuGqjRSJH2vlB44GzRiFoJjXJOJGZ0hdagXl1ARTKul1NF QukGMeJa1xlXzEk2K1sT7inGHEHTO5KD4RyyVFaDTnhWtvDfmDZt5R/Ipfc7KMmc dObDKqWe/TGoKM5noj3dvafhNFZ9mDCCBAQwggLsoAMCAQICCBh6qajCliEMMA0G CSqGSIb3DQEBCwUAMGIxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpBcHBsZSBJbmMu MSYwJAYDVQQLEx1BcHBsZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEWMBQGA1UE AxMNQXBwbGUgUm9vdCBDQTAeFw0xMjAyMDEyMjEyMTVaFw0yNzAyMDEyMjEyMTVa MHkxLTArBgNVBAMMJERldmVsb3BlciBJRCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEmMCQGA1UECwwdQXBwbGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxEzARBgNV BAoMCkFwcGxlIEluYy4xCzAJBgNVBAYTAlVTMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAiXZPBluaQe6lIysCo1/Xcz/ANbCLhAo/BiR/p5U/608Ok6+0 DtDIPuVtGLMf6IlHv9cJCOT/VpgpFeeUnbk1owrNtMDh4mD0yuwpeEVpaWBrX4qS /J4j5jrCIrMxTxy68rY0WULusKkCAxiRBLazeC4zH4BFDUVvuw5aW38659gI1wsO Mm37hjbkbKvEEYpwhCaqn0TR8bjGe5QXm0j3C1gWuiPFnxU5fspdwzJfD+BSf0Dq vqwIZJVbyRqc5YDKH2pEHGw+xLAmHx3se69eoGo9R6lYEjE/IHYobR0csMJOEWkm i8vW0BGCyU4P8VZ00NkIS2Z4oqusp+LSTIdZyQIDAQABo4GmMIGjMB0GA1UdDgQW BBRXF+2iz9x8mKEQ4Py+hy0s8uMXVDAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQY MBaAFCvQaUeUdgn+9GuNLkCm90dNfwheMC4GA1UdHwQnMCUwI6AhoB+GHWh0dHA6 Ly9jcmwuYXBwbGUuY29tL3Jvb3QuY3JsMA4GA1UdDwEB/wQEAwIBhjAQBgoqhkiG 92NkBgIGBAIFADANBgkqhkiG9w0BAQsFAAOCAQEAQjl0a6HcxqSPNyqMsx0KRLyV LH+8WbisYfsHkJIyudS/O8FQOWpEdKLsWx9w5ardS2wcI3EtX9HFk77um4pwZYKd FuMaEBeJLajN/Qx4WEkMKH8z7gB6G7R2rLa1u0/fqBudyBmXSgtWZy/CPrazxIM6 8HdtdMQuI1HumqUDb2D0pUinBsK7WuIfH0ZFfuSX9ScQtyAicm9y2sZQdcU9JY9d owDpnzaMSDmPszvqkIAulZpg9HjO9A4KUz6i+k/YHq6ElY0yvFZNiel4GOCsmkK6 ekYbhKKJzhToiNFYi/auVsQsBSpFrwvZS6kCDzSsiMdhVYlEySdzB+6C5U71cDGC An8wggJ7AgEBMIGjMIGWMQswCQYDVQQGEwJVUzETMBEGA1UECgwKQXBwbGUgSW5j LjEsMCoGA1UECwwjQXBwbGUgV29ybGR3aWRlIERldmVsb3BlciBSZWxhdGlvbnMx RDBCBgNVBAMMO0FwcGxlIFdvcmxkd2lkZSBEZXZlbG9wZXIgUmVsYXRpb25zIENl cnRpZmljYXRpb24gQXV0aG9yaXR5Agh3mRQz7FJtYzAJBgUrDgMCGgUAoIGxMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDIwMTAx MTExNFowIwYJKoZIhvcNAQkEMRYEFNKi/xYPqnN6zp/RogVZBZ3ICGOBMFIGCSqG SIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIB AJQtrcrRd/3PLS9rhey0RyU1ZRnuB4Ib+y/wAan3k+fRNpA70F9kaxxcme78eqho HH5rvizY4InvrG1wjtpYeickMHp+s0E51j1AbVxOgZ/UiEgjLRq9Dv5OCPgKoLaB lsyCj41baXvlqzXZ8RaP7Li2SPLpdksqLE5yegiN+yMIiEPfNAtmaRLN3CNnbbMf X1bF4ifgyhy3P1VGPPk+WTiQyu0VqySrlhz0Ux9+acB/TFUrymFEKxJ/7bM//4nL UpEQVlnj9rl3OYzhYgDsQgz0kGU+6UG7Iw6gB9xFAMeE/1Y5Xrs2UdjBVC9hkSy8 r1+2rPF1yixiWjiORNk4kyU= -----END PKCS7----- Regards, Cory On Fri, Jan 12, 2018 at 5:14 AM, nullius via bitcoin-dev wrote: > On 2018-01-12 at 08:54:12 +0000, Peter Todd wrote: >> >> While a clunky way to do it, you can use the `-signer` option to tell >> OpenSSL to write the signer's certificate to a file. That certificate can >> then be compared to the one from the repo, which was still in the repo as of >> the (signed!) v0.15.1 tag. >> >> >> Fun fact: OpenTimestamps has git integration, which means you can extract >> a OTS proof from 2016 for that certificate from the repo: >> >> $ git checkout v0.15.1 >> $ ots git-extract share/certs/BitcoinFoundation_Apple_Cert.pem >> share/certs/BitcoinFoundation_Apple_Cert.pem.ots >> 36f60a5d5b1bc9a12b87d6475e3245b8236775e4 >> $ ots verify share/certs/BitcoinFoundation_Apple_Cert.pem.ots >> Assuming target filename is >> 'share/certs/BitcoinFoundation_Apple_Cert.pem' >> Success! Bitcoin attests data existed as of Thu Oct 13 14:08:59 2016 >> EDT >> >> Homework problem: write a paragraph explaining how the proof generated by >> the above three commands are crypto snakeoil that proved little. :) > > > It says, ?Bitcoin attests data existed?. Within the scope of those three > commands, I don?t see any proof of who put it there. Does OTS check the PGP > signatures on *commits* when it does that `git-extract`? The signature on > the v0.15.1 tag is irrelevant to that question; and FWIW, I don?t see *that* > signature being verified here, either. > Second paragraph: Moreover, with the breaking of SHA-1, it *may* be > feasible for some scenario to play out involving two different PEMs with the > same hash, but different public keys (and thus different corresponding > private keys). I don?t know off the top of my head if somewhere could be > found to stash the magic bits; and the overall scenario would need to be a > bit convoluted. I think a malicious committer who lacked access to the > signing key *may* be able to create a collision between the real > certificate, and a certificate as for which he has the private key?then > switch them, later. Maybe. I would not discount the possibility off-hand. > OTS would prove nothing, if he had the foresight to obtain timestamps > proving that both certificates existed at the appropriate time (which they > would need to anyway; it is not a post facto preimage attack). > >> [...] >> >> What's nice about OpenPGP's "clearsigned" format is how it ignores >> whitespace; a replica of that might be a nice thing for OTS to be able to do >> too. Though that's on low priority, as there's some tricky design choices(1) >> to be made about how to nicely nest clearsigned PGP within OTS. >> >> >> 1) For example, I recently found a security hole related to clearsigned >> PGP recently. Basically the issue was that gpg --verify will return true on >> a file that looks like the following: >> >> 1d7a363ce12430881ec56c9cf1409c49c491043618e598c356e2959040872f5a >> foo-v2.0.tar.gz >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 >> foo-v1.0.tar.gz >> -----BEGIN PGP SIGNATURE----- >> >> >> -----END PGP SIGNATURE----- >> >> The system I was auditing then did something like this to verify that the >> file was signed: >> >> set -e # exit immediately on error >> gpg --verify SHA256SUMS.asc >> cat SHA256SUMS.asc | grep foo-v2.0.tar.gz >> >> >> While it makes it a bit less user friendly, the fact that PKCS7's encoding >> made it impossible to see the message you signed until it's been properly >> verified is a good thing re: security. > > > Potential solutions using PGP: > > 0. Don?t use clearsigning. > > 1. Use a detached signature. > > 2. Use `gpg --verify -o -` and pipe that to `grep`, rather than illogically > separating verification from use of data. (By the way, where is the *hash* > verified? Was `grep` piped to `sha256sum -c`?) > > 3. Have shell scripts written by somebody who knows how to think about > security, and/or who knows how to RTFM; quoting gpg(1): > >> Note: When verifying a cleartext signature, gpg verifies only what makes >> up the cleartext signed data and not any extra data outside of the cleartext >> signature or the header lines directly following the dash marker line. The >> option --output may be used to write out the actual signed data, but there >> are other pitfalls with this format as well. It is suggested to avoid >> cleartext signatures in favor of detached signatures. > > > 4. Obtain an audit from Peter Todd. > >> And yes, I checked: Bitcoin Core's contrib/verifybinaries/verify.sh isn't >> vulnerable to this mistake. :) > > > P.S., oh my! *Unsigned data:* > >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > -- > nullius at nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C > Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested: > 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG) (PGP RSA: 0x36EBB4AB699A10EE) > ??If you?re not doing anything wrong, you have nothing to hide.? > No! Because I do nothing wrong, I have nothing to show.? ? nullius > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > From ZmnSCPxj at protonmail.com Sun Feb 4 22:24:36 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Sun, 04 Feb 2018 17:24:36 -0500 Subject: [bitcoin-dev] RBF Wallet Algorithms (Was: Transaction Merging (bip125 relaxation)) Message-ID: Good Morning Rhavar, I have been trying to conceptualize an algorithm precisely for RBF, and I agree that "tracking the mess" is a significant issue... > Full backstory: I have been trying to use bip125 (Opt-in Full Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I owe John 1 bitcoin, and have promised to pay him immediately: Instead of creating a whole new transaction if I have an in-flight (unconfirmed) transaction, I can follow the rules of bip125 to create a replacement that accomplishes this goal. > > From a "coin selection" point of view, this was significantly easier than > I had anticipated. I was able to encode the rules in my linear model and > feed in all my unspent and in-flight transactions and it can solve it without difficulty. > > However, the real problem is tracking the mess. Consider this sequence of events: > 1) I have unconfirmed transaction A > 2) I replace it with B, which pays John 1 BTC > 3) Transaction A gets confirmed > > So now I still owe John 1 BTC, however it's not immediately clear if > it's safe to send to him without waiting $n transactions. However even > for a small $n, this breaks my promise to pay him immediately. > > One possible solution is to only consider a transaction "replaceable" if it has change, so if the original transaction confirms -- payments can immediately be made that source the change, and provide safety in a reorg. > > However, this will only work <50% of the time for me (most transactions > don't have change) and opens a pandora's box of complexity. For this example, I believe it is possible to assure correct operation without changes to the current RBF policy. Presumably, the problematic sequence of events is this: 1. You need to pay Paul. 2. You make transaction A that pays to Paul. It has no change output. 3. You need to pay John. 4. You see transaction A is unconfirmed. Using A as basis, you make transaction B that pays to Paul, John. It replaces A. 5. Transaction A confirms once (because the B transaction did not propagate to the lucky miner quickly enough) 6. You still have a pending commitment to pay John, so you make a transaction C that pays to John. 7. A reorg occurs, transaction A is removed from history. 8. Transaction B and transaction C confirm, double-paying John. This can be fixed by ensuring that transaction C is incompatible with B, but compatible with A. By "compatibility", we mean, "A transaction T is incompatible with U if T cannot confirm if U confirms, and U cannot confirm if T confirms." If transaction A has no change output, then in order for A to be incompatible with B, with B paying both Paul and John, means that B has more spent inputs than A. Else where would the extra funds to pay John come from? (assuming you are not taking from Paul to pay John) If so, it means that there is some input that B spends, which A does not spend. So we can make a transaction C that spends this input (the one which B spends that A does not spend). This makes C compatible with A, but incompatible with B. So you can still work, even without a change output on A, to ensure that your transaction C cannot be confirmed if B confirms. Thus: 1. If A has some change output, ensure C spends that output. Presumably if B is incompatible with A (after all, you tried to replace A with B), then C is incompatible with B as C is dependent on A confirming. 2. If A has no change output, then if you increased your spending to make transaction B, then logically B has some input that is not in A (otherwise where would the extra funds have come from...). Then ensure C spends that input of B that is not in A, making it directly incompatible with B. This ensures that either A+C confirm, or B confirms. (Again, the complications are considerable! We can only show that it is possible in theory, but whether it is feasible in practice to implement in some program that can be debugged and maintained is another issue) A vague idea I have formed is to use some sort of vector of candidate TXOs you control. Items are appended to this vector lazily as per your coin policy. Transactions mark how far in this vector they spend (i.e. a high-water mark for that transaction). If a previous confirmed transaction you wrote has a change output, you always use that change output and try to get more coins from this vector (starting after the previous confirmed transaction high-water mark) if the change output is not enough. If a previous confirmed transaction you wrote has no change output, then you get more coins from this vector (again starting from the previous confirmed transaction high-water mark). The vector is extended lazily from your set of controlled coins. Older entries in this vector may be dropped once transactions confirm deeply enough that it is unlikely to be reorged (say 144 blocks); the exact policy is that if a transaction confirms deeply enough, then everything from its high-waiter mark to below can be pruned from this vector. The above vague idea precludes you from reoptimizing transactions, however; your replacements either have the same set of inputs, or a strict superset of inputs, as the previous transaction. Regards, ZmnSCPxj -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at xiph.org Mon Feb 5 05:58:43 2018 From: greg at xiph.org (Gregory Maxwell) Date: Mon, 5 Feb 2018 05:58:43 +0000 Subject: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption Message-ID: In my post on taproot I showed a simple commitment scheme for scripts that is very efficient that there exists some collection of pubkeys (like an M-of-N or even N-of-N) whos authorization is an acceptable alternative to whatever other conditions we might want to impose on a coin. If this holds then when spends happen via the plain signature path the existence of the alternative is never revealed, providing privacy with improved efficiency compared to not being private at all. Taproot suffers from a limitation that it only natively provides for one alternative. Trees or cascades of taproots can be done, but they have less privacy and efficiency than just a single level. E.g. a tree commitment has overhead that grows with the log of the number of alternatives. However, under the taproot assumption-- that there exists some monotone function on plain public keys and nothing else that is sufficient to authorize a transaction-- we can do even better. With graftroot, the participants establish a threshold key, optionally with a taproot alternative, just as they do with taproot. At any time, they can delegate their ability to sign to a surrogate script by signing that script (and just the script) with their taproot key, and sharing that delegation with whomever they choose. Later, when it comes time to spend the coin, if the signers aren't available and the script must be used, the redeeming party does whatever is required to satisfy the script (e.g. provides their own signature and a timelock, or whatnot) and presents that information along with the signer's signature of the script. The result is that instead of allowing only one alternative an unlimited number of alternatives can be provided. All are executed with equal efficiency to a single alternative, and the number of them is hidden without overhead. Alternatives can be provided for existing coins too, without requiring they get moved-- movement is only required to destroy the ability to use alternatives by changing keys. Allowing this kind of delegation makes sense because the same signers could have just signed the transaction outright. The new script simply stands in for them, if they're not available or cooperating. No special conditions are needed outside of the surrogate script on when the surrogate is allowed, because they can be written inside the surrogate. We've discussed delegation in script back to at least 2012-- with speculation that enabling it may have been an original motivation behind codeseperator. ... but these design discussions have gotten mired in how to express and connect the levels of delegation. But the case where delegation is accomplished with a simple unconditional signature is an especially simple case, and under the taproot assumption the only case that is ever needed. A naive implementation of this idea requires a complete signature every time a surrogate is used, which means 64 bytes of data (assuming 128 bit ECC). This is higher overhead than taproot. However, the non-interactive schnorr aggregation trick[1] can be applied to merge the S values of all graftroots and signatures in a transaction into a single aggregate. With this approach only a single R value for each graftroot need be published, lowering the overhead to ~32 bytes-- the same as taproot. This has a side benefit of binding the published grafts to a particular transaction, which might help avoid some screwups. In cases where the taproot assumption doesn't hold, taproot can still be used by setting the public key to a NUMS point, which preserves privacy (e.g. you can't distinguish txn where the key could never have been used.) A similar thing can be done for graftroot if the signature is not a proof of knowledge (commits to the public key): you select the signature in a NUMS manner, and then recover the applicable public key. Though this can't be done if the signature is a PoK, and it's probably a pretty good idea to make it a PoK. The primary limitation of this approach compared to taproot alternatives and trees is that it requires that anyone who wants to make use of a particular surrogate to interact with the participants and store the resulting signature because a single party couldn't compute it again on their own from public data. For trees and taproot alternatives, the alternatives can be setup without any interaction with the participants. The primary advantage is that it scales to any number of alternatives with small constant overhead, can be delegated after the fact, and can still be spent by the participants without overhead. Summarizing: A coin's authorizing contract is decomposed into a top level OR between a monotone function of pubkeys (such as N of N) and any number of arbitrary surrogate scripts which are acceptable authorizations. A key aggregate (see [2]) is formed, and is used to sign each of the the surrogates. Participants save these signatures. Later, when it comes time to spend the coin, if the pubkey holders are unwilling or unavailable, the spender presents and satisfies the relevant surrogate along with it's signature R-value and non-interactively aggregates the S-value into the transaction's overall aggregate signature. The result is 0-overhead if the signers cooperate, or ~32-byte overhead (plus the script) if they don't. This avoids the log() overhead of tree based schemes, and allows delegation to take place before or after the fact but requires storage. The potential for unexpected surrogate replay if keys are reused in foolish ways also needs to be kept in mind, though it may be somewhat mitigated by aggregation. The existence of unused surrogates is completely hidden. I believe this general design is simple and powerful enough that it avoids the rathole that earlier delegation discussions have suffered. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014272.html And the secure construction at: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014308.html [2] https://eprint.iacr.org/2018/068 From bitcoin-dev at rgrant.org Mon Feb 5 15:56:23 2018 From: bitcoin-dev at rgrant.org (Ryan Grant) Date: Mon, 5 Feb 2018 10:56:23 -0500 Subject: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption In-Reply-To: References: Message-ID: Am I reading correctly that this allows unilateral key rotation (to a previously unknown key), without invalidating the interests of other parties in the existing multisig (or even requiring any on-chain transaction), at the cost of storing the signed delegation? From greg at xiph.org Mon Feb 5 19:58:24 2018 From: greg at xiph.org (Gregory Maxwell) Date: Mon, 5 Feb 2018 19:58:24 +0000 Subject: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption In-Reply-To: References: Message-ID: On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant wrote: > Am I reading correctly that this allows unilateral key rotation (to a > previously unknown key), without invalidating the interests of other > parties in the existing multisig (or even requiring any on-chain > transaction), at the cost of storing the signed delegation? Yes, though I'd avoid the word rotation because as you note it doesn't invalidate the interests of any key, the original setup remains able to sign. You could allow a new key of yours (plus everyone else) to sign, assuming the other parties agree... but the old one could also still sign. From ZmnSCPxj at protonmail.com Mon Feb 5 09:27:07 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 05 Feb 2018 04:27:07 -0500 Subject: [bitcoin-dev] Taproot: Privacy preserving switchable scripting In-Reply-To: References: Message-ID: Good morning Greg, I am probably being exceedingly naive, but I would like to compare Taproot to a generalization of funding transactions. For instance, CoinSwapCS: 1. It uses an HTLC in an off-chain transaction, and a funding transaction TX0 whose output is a "simple" 2-of-2. 2. The HTLC tx spends this 2-of-2. 3. If a branch of the HTLC succeeds, the parties contact each other and create a replacement of the (unconfirmed and unbroadcasted but signed) HTLC tx that assigns the funds to the correct owners. 4. If the above step fails, individual parties can in isolation publish the HTLC tx and provide its requirements. Both of #3 and #4 above, appear to me naively as similar to the two "top" cases of Taproot, i.e. either C is signed by all parties, or S is revealed and fulfilled. The important bits of this "generalized funding transaction" pattern is: 1. The contract that enforces correct behavior spends an unsigned and unbroadcasted funding transaction output (which requires N-of-N). 2. The enforcement contract is signed first by all parties before the funding transaction is signed by anybody. This is possible due to SegWit. 3. Then, when all parties are sure they have the fully-signed smart contract, the initial funding transaction is signed and broadcast and confirmed. 4. When the condition that the contract requires is achieved, then the parties contact each other and try to jointly create a simpler transaction that spends the funding transaction directly to whoever gets the money in the correct proportion. This avoids publishing the smart contract onchain, and looks like an ordinary N-of-N spend. 5. If they fail to get all required signatures for any reason, any party can publish the enforcement contract transaction and subsequently fulfill its conditions in another transaction. Admittedly, Taproot if added to the consensus would reduce the number of transactions by 1 in the "S is revealed" case. But the "generalized funding transaction" pattern is already possible today, and MuSig (to my limited understanding) can be used to make it indistinguishable from 1-of-1 (so, possibly, make it P2WPKH?). (I am probably neglecting something very simple and direct, however...) Regards, ZmnSCPxj -------- Original Message -------- On January 23, 2018 8:30 AM, Gregory Maxwell via bitcoin-dev wrote: >Interest in merkelized scriptPubKeys (e.g. MAST) is driven by two main > areas: efficiency and privacy. Efficiency because unexecuted forks of > a script can avoid ever hitting the chain, and privacy because hiding > unexecuted code leaves scripts indistinguishable to the extent that > their only differences are in the unexecuted parts. > > As Mark Friedenbach and others have pointed out before it is almost > always the case that interesting scripts have a logical top level > branch which allows satisfaction of the contract with nothing other > than a signature by all parties. Other branches would only be used > where some participant is failing to cooperate. More strongly stated, > I believe that any contract with a fixed finite participant set > upfront can be and should be represented as an OR between an N-of-N > and whatever more complex contract you might want to represent. > > One point that comes up while talking about merkelized scripts is can > we go about making fancier contract use cases as indistinguishable as > possible from the most common and boring payments. Otherwise, if the > anonymity set of fancy usage is only other fancy usage it may not be > very large in practice. One suggestion has been that ordinary > checksig-only scripts should include a dummy branch for the rest of > the tree (e.g. a random value hash), making it look like there are > potentially alternative rules when there aren't really. The negative > side of this is an additional 32-byte overhead for the overwhelmingly > common case which doesn't need it. I think the privacy gains are > worth doing such a thing, but different people reason differently > about these trade-offs. > > It turns out, however, that there is no need to make a trade-off. The > special case of a top level "threshold-signature OR > arbitrary-conditions" can be made indistinguishable from a normal > one-party signature, with no overhead at all, with a special > delegating CHECKSIG which I call Taproot. > > Let's say we want to create a coin that can be redeemed by either > Alice && Bob or by CSV-timelock && Bob. > > Alice has public A, Bob has pubkey B. > > We compute the 2-of-2 aggregate key C = A + B. (Simplified; to > protect against rogue key attacks you may want to use the MuSig key > aggregation function [1]) > > We form our timelock script S = " OP_CSV OP_DROP B OP_CHECKSIGVERIFY" > > Now we tweak C to produce P which is the key we'll publish: P = C + H(C||S)G. > > (This is the attack hardened pay-to-contract construction described in [2]) > > Then we pay to a scriptPubKey of [Taproot supporting version] [EC point P]. > > Now Alice and Bob-- assuming they are both online and agree about the > resolution of their contract-- can jointly form a 2 of 2 signature for > P, and spend as if it were a payment to a single party (one of them > just needs to add H(C||S) to their private key). > > Alternatively, the Taproot consensus rules would allow this script to > be satisfied by someone who provides the network with C (the original > combined pubkey), S, and does whatever S requires-- e.g. passes the > CSV check and provides Bob's signature. With this information the > network can verify that C + H(C||S) == P. > > So in the all-sign case there is zero overhead; and no one can tell > that the contract alternative exists. In the alternative redemption > branch the only overhead is revealing the original combined pubkey > and, of course, the existence of the contract is made public. > > This composes just fine with whatever other merkelized script system > we might care to use, as the S can be whatever kind of data we want, > including the root of some tree. > > My example shows 2-of-2 but it works the same for any number of > participants (and with setup interaction any threshold of > participants, so long as you don't mind an inability to tell which > members signed off). > > The verification computational complexity of signature path is > obviously the same as any other plain signature (since its > indistinguishable). Verification of the branch redemption requires a > hash and a multiplication with a constant point which is strictly more > efficient than a signature verification and could be efficiently fused > into batch signature validation. > > The nearest competitor to this idea that I can come up with would > supporting a simple delegation where the output can be spent by the > named key, or a spending transaction could provide a script along with > a signature of that script by the named key, delegating control to the > signed script. Before paying into that escrow Alice/Bob would > construct this signature. This idea is equally efficient in the common > case, but larger and slower to verify in the alternative spend case. > Setting up the signature requires additional interaction between > participants and the resulting signature must be durably stored and > couldn't just be recomputed using single-party information. > > I believe this construction will allow the largest possible anonymity > set for fixed party smart contracts by making them look like the > simplest possible payments. It accomplishes this without any overhead > in the common case, invoking any sketchy or impractical techniques, > requiring extra rounds of interaction between contract participants, > and without requiring the durable storage of other data. > > > [1] https://eprint.iacr.org/2018/068 > [2] https://blockstream.com/sidechains.pdf Appendix A > >bitcoin-dev mailing list >bitcoin-dev at lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > From cannon at cannon-ciota.info Tue Feb 6 02:08:24 2018 From: cannon at cannon-ciota.info (CANNON) Date: Tue, 6 Feb 2018 02:08:24 +0000 Subject: [bitcoin-dev] NIST 8202 Blockchain Technology Overview In-Reply-To: References: <6d24833d-f127-04ea-d180-c69409de16a5@cannon-ciota.info> <6d92d8da-052d-f997-f441-0713acd72e85@cannon-ciota.info> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/31/2018 11:16 AM, Damian Williamson wrote: > I disagree with the correctness of the following statement: > > >> Rather than implementing the SegWit changes, the developers of Bitcoin Cash decided to simply increase the blocksize. > > > I would suggest "Rather than being satisfied with the implementation of SegWit changes alone, the developers of > Bitcoin Cash decided to also increase the blocksize. > > > Regards, > > Damian Williamson You do realize that segwit includes many improvements of which are unrelated to scaling? These same improvements of which simply increasing the blocksize alone would not fix or enable. Segwit is not just a blocksize increase. Bitcoin Cash, while increasing the blocksize directly, from my understanding has yet to implement the improvements and capabilities that segwit enables. One example being, with transactions hashes being able to be calculated in advanced prior to signing (due to the signature being in different section than that used to calculate the transaction ID) it is possible to create transaction trees, enhanced smart contracts, trustless mixing protocols, micropayment networks, etc... Segwit also increases the security of signatures. There are lots of other things segregated witness enables as well. By saying "..segwit changes alone.... decided to also..." Bitcoin Cash has not implemented segwit. Bitcoin Cash only increased the blocksize. that wording above at least from the way I read it, seems to imply that Bitcoin Cash has segwit. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJaeQ3IAAoJEAYDai9lH2mwKkQP/3dgYApq1qv2lGIyZIdeN9SE D5AuXPqFQYAoMwhC0RPNQU/jUisKIyd6zm4XCIm6KPufCtXkjfH9FLhd0ThbCTcy Gk+pYYRBzSuBZdPBKg0DHu7alRETtxbdtUI0zDfERt1FFZb+HmcDcGTfwdVci3fa jBiFXq1R+myMW5xdB44dipSk5kBhcpx2zitr1bIA4rF11QbxKAmzU7iPdRpA+PXz gB9NImc1Dbz+TEA50tdq3v9Ov3x7m7F+QtBnqyLAigJh6XKa6guCfwKIGoawRGwZ v2ur7T+Qh3KGRXCBlHnxgtFte16wHagwvsVgE5EEmJR0yJUc/4XU2kCGANVNDZ/P pphqk8pruQ5rjQ8S+s6i5XG8oHVSB2fDh56NvPY7msA72j+Gk+XneV2eJbEAdjhb 9Ci7u1uPJL3pb3c/ZOwQvpIRV3tRjlh0DertWkd3Li5RZLO3uFvBTxNxrni6+9bf /cmAOwfHjoUp8BX/nvgMjpIDCoEu+Rv9IO/ok3s3mX300JbczAdGbXbsPTE5G+DI RB1kSmszwst8wOlOAsdVqk/iKRJdN9daTGGN6aE/wjkpSg8rW9BOaoI2X9t4oXCU +oe/WlgkxhxPcNyhKpLeeYVe6nFX2fjU+THyyiAq/LJ/qHU/brKpXc4NesCVHhQP BBlxiN0E4gndMGs/Lx89 =+UCK -----END PGP SIGNATURE----- From willtech at live.com.au Tue Feb 6 07:07:26 2018 From: willtech at live.com.au (Damian Williamson) Date: Tue, 6 Feb 2018 07:07:26 +0000 Subject: [bitcoin-dev] NIST 8202 Blockchain Technology Overview In-Reply-To: References: <6d24833d-f127-04ea-d180-c69409de16a5@cannon-ciota.info> <6d92d8da-052d-f997-f441-0713acd72e85@cannon-ciota.info> , Message-ID: Then you have my apology, I will not claim to be any kind of advocate or user of Bitcoin Cash but *had* understood that segwith had been enabled. Clearly my mistake. Regards, Damian Williamson ________________________________ From: CANNON Sent: Tuesday, 6 February 2018 1:08:24 PM To: Damian Williamson; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] NIST 8202 Blockchain Technology Overview -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/31/2018 11:16 AM, Damian Williamson wrote: > I disagree with the correctness of the following statement: > > >> Rather than implementing the SegWit changes, the developers of Bitcoin Cash decided to simply increase the blocksize. > > > I would suggest "Rather than being satisfied with the implementation of SegWit changes alone, the developers of > Bitcoin Cash decided to also increase the blocksize. > > > Regards, > > Damian Williamson You do realize that segwit includes many improvements of which are unrelated to scaling? These same improvements of which simply increasing the blocksize alone would not fix or enable. Segwit is not just a blocksize increase. Bitcoin Cash, while increasing the blocksize directly, from my understanding has yet to implement the improvements and capabilities that segwit enables. One example being, with transactions hashes being able to be calculated in advanced prior to signing (due to the signature being in different section than that used to calculate the transaction ID) it is possible to create transaction trees, enhanced smart contracts, trustless mixing protocols, micropayment networks, etc... Segwit also increases the security of signatures. There are lots of other things segregated witness enables as well. By saying "..segwit changes alone.... decided to also..." Bitcoin Cash has not implemented segwit. Bitcoin Cash only increased the blocksize. that wording above at least from the way I read it, seems to imply that Bitcoin Cash has segwit. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJaeQ3IAAoJEAYDai9lH2mwKkQP/3dgYApq1qv2lGIyZIdeN9SE D5AuXPqFQYAoMwhC0RPNQU/jUisKIyd6zm4XCIm6KPufCtXkjfH9FLhd0ThbCTcy Gk+pYYRBzSuBZdPBKg0DHu7alRETtxbdtUI0zDfERt1FFZb+HmcDcGTfwdVci3fa jBiFXq1R+myMW5xdB44dipSk5kBhcpx2zitr1bIA4rF11QbxKAmzU7iPdRpA+PXz gB9NImc1Dbz+TEA50tdq3v9Ov3x7m7F+QtBnqyLAigJh6XKa6guCfwKIGoawRGwZ v2ur7T+Qh3KGRXCBlHnxgtFte16wHagwvsVgE5EEmJR0yJUc/4XU2kCGANVNDZ/P pphqk8pruQ5rjQ8S+s6i5XG8oHVSB2fDh56NvPY7msA72j+Gk+XneV2eJbEAdjhb 9Ci7u1uPJL3pb3c/ZOwQvpIRV3tRjlh0DertWkd3Li5RZLO3uFvBTxNxrni6+9bf /cmAOwfHjoUp8BX/nvgMjpIDCoEu+Rv9IO/ok3s3mX300JbczAdGbXbsPTE5G+DI RB1kSmszwst8wOlOAsdVqk/iKRJdN9daTGGN6aE/wjkpSg8rW9BOaoI2X9t4oXCU +oe/WlgkxhxPcNyhKpLeeYVe6nFX2fjU+THyyiAq/LJ/qHU/brKpXc4NesCVHhQP BBlxiN0E4gndMGs/Lx89 =+UCK -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From helder.garcia at gmail.com Thu Feb 8 02:49:45 2018 From: helder.garcia at gmail.com (Helder Garcia) Date: Thu, 8 Feb 2018 00:49:45 -0200 Subject: [bitcoin-dev] BIP0008 clarification Message-ID: <6EAA8D06-3A20-4BBA-BE2E-95B42BCCE7D3@gmail.com> Hi, I?m trying to understand the process of signalling and activation of updates in bitcoin. Following BIP34, BIP9, I got into BIP8. In my understanding of what I read there, an update will be activated even if the threshold of 95% signalling is not reached in STARTED state, as soon as blockchain height is equal or higher than timeout_height. Is my understanding correct? If so, isn?t it a risk to activate a change even if you don?t have the majority of hash power accepting it? Thanks for your time, ? Helder Garcia From belcher at riseup.net Thu Feb 8 16:51:59 2018 From: belcher at riseup.net (Chris Belcher) Date: Thu, 8 Feb 2018 16:51:59 +0000 Subject: [bitcoin-dev] Electrum Personal Server alpha release Message-ID: <8b7bd786-9bc3-efb2-a8ed-0b703e246728@riseup.net> Electrum is a popular bitcoin wallet, but it is not a full node wallet as it synchronizes itself using third-party Electrum servers. The servers must be trusted to verify the rules of bitcoin, they can trick Electrum wallets into accepting fake bitcoin transactions which, for example, print infinite money. Bitcoin's security model requires that most economic activity is backed by full nodes. The Electrum servers must also be trusted with the user's privacy, as wallets send all their bitcoin addresses to the server. Spying on wallets is not much more complicated than simply grepping the server logs. Electrum wallets by default also connect to servers using their own IP address, linking it further to their revealed bitcoin addresses. A way to avoid these problems is for users to run their own Electrum server and connect their wallets only to it. But this requires significant resource usage: the full unpruned blockchain, transaction index and an extra address index, as well as more RAM and CPU usage compared to just a full node. Servers are not well suited to being shut down and started up again, they are typically always online. Electrum servers store a database of every bitcoin address ever used, which is inherently not scalable. This is resource-intensive and therefore pushes users towards centralized solutions. An alternative way would be to store only your own addresses and transactions. Introducing Electrum Personal Server; an implementation of the Electrum server protocol which fulfills the specific need of using the Electrum UI with full node verification and privacy, but without the heavyweight server backend, for a single user. It allows the user to benefit from all of Bitcoin Core's resource-saving features like pruning, blocksonly and disabled txindex. All of Electrum's feature-richness like hardware wallet integration, multisignature wallets, offline signing, mnemonic recovery phrases and so on can still be used, but backed by the user's own full node. An alpha version of Electrum Personal Server can be found on the repository: https://github.com/chris-belcher/electrum-personal-server Before using, the wallet user must configure Electrum Personal Server with their master public key and those addresses are imported into Bitcoin Core as watch-only. If the wallet contains historical transactions then it must be rescanned. One of Electrum's motivating features is "instant on", which is therefore traded away when using Electrum Personal Server in return for full node verification and privacy. Although if a brand new empty wallet is created there is no need to rescan. A script like Electrum Personal Server is also well suited to use private transaction broadcasting tech like dandelion or broadcasting through tor. Using Electrum with Electrum Personal Server is probably the most resource-efficient way right now to use a hardware wallet connected to your own full node. People who make use of Blockstream Satellite could use it to have an off-the-grid node connected to Electrum if that is their preferred wallet. In the situation of a traveller staying a cheap hostels, they could sync their node every couple of days to download recent blocks and use Electrum. Hopefully this software can be part of the plan to get full node wallets into the hands of as many people as possible. The same kind of ideas could be applied to other lightweight wallets. For example a full nodes can run on smartphones with pruning and blocksonly, then a similar script would allow the user to connect their Samourai Wallet, Breadwallet or GreenAddress app to their own full node. Further Reading: * https://bitcointalk.org/index.php?topic=2664747.msg27179198 * https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html * https://bitcointalk.org/index.php?topic=1634967.0;all From kanzure at gmail.com Thu Feb 8 17:49:23 2018 From: kanzure at gmail.com (Bryan Bishop) Date: Thu, 8 Feb 2018 11:49:23 -0600 Subject: [bitcoin-dev] Fwd: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Olaoluwa Osuntokun Date: Mon, Feb 5, 2018 at 11:26 PM Subject: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning To: lightning-dev Hi Y'all, A common question I've seen concerning Lightning is: "I have five $2 channels, is it possible for me to *atomically* send $6 to fulfill a payment?". The answer to this question is "yes", provided that the receiver waits to pull all HTLC's until the sum matches their invoice. Typically, one assumes that the receiver will supply a payment hash, and the sender will re-use the payment hash for all streams. This has the downside of payment hash re-use across *multiple* payments (which can already easily be correlated), and also has a failure mode where if the sender fails to actually satisfy all the payment flows, then the receiver can still just pull the monies (and possibly not disperse a service, or w/e). Conner Fromknecht and I have come up with a way to achieve this over Lightning while (1) not re-using any payment hashes across all payment flows, and (2) adding a *strong* guarantee that the receiver won't be paid until *all* partial payment flows are extended. We call this scheme AMP (Atomic Multi-path Payments). It can be experimented with on Lightning *today* with the addition of a new feature bit to gate this new feature. The beauty of the scheme is that it requires no fundamental changes to the protocol as is now, as the negotiation is strictly *end-to-end* between sender and receiver. TL;DR: we repurpose some unused space in the onion per-hop payload of the onion blob to signal our protocol (and deliver some protocol-specific data), then use additive secret sharing to ensure that the receiver can't pull the payment until they have enough shares to reconstruct the original pre-image. Protocol Goals ============== 1. Atomicity: The logical transaction should either succeed or fail in entirety. Naturally, this implies that the receiver should not be unable to settle *any* of the partial payments, until all of them have arrived. 2. Avoid Payment Hash Reuse: The payment preimages validated by the consensus layer should be distinct for each partial payment. Primarily, this helps avoid correlation of the partial payments, and ensures that malicious intermediaries straddling partial payments cannot steal funds. 3. Order Invariance: The protocol should be forgiving to the order in which partial payments arrive at the destination, adding robustness in the face of delays or routing failures. 4. Non-interactive Setup: It should be possible for the sender to perform an AMP without directly coordinating with the receiving node. Predominantly, this means that the *sender* is able to determine the number of partial payments to use for a particular AMP, which makes sense since they will be the one fronting the fees for the cost of this parameter. Plus, we can always turn a non-interactive protocol into an interactive one for the purposes of invoicing. Protocol Benefits ================= Sending pay payments predominantly over an AMP-like protocol has several clear benefits: - Eliminates the constraint that a single path from sender to receiver with sufficient directional capacity. This reduces the pressure to have larger channels in order to support larger payment flows. As a result, the payment graph be very diffused, without sacrificing payment utility - Reduces strain from larger payments on individual paths, and allows the liquidity imbalances to be more diffuse. We expect this to have a non-negligible impact on channel longevity. This is due to the fact that with usage of AMP, payment flows are typically *smaller* meaning that each payment will unbalance a channel to a lesser degree that with one giant flow. - Potential fee savings for larger payments, contingent on there being a super-linear component to routed fees. It's possible that with modifications to the fee schedule, it's actually *cheaper* to send payments over multiple flows rather than one giant flow. - Allows for logical payments larger than the current maximum value of an individual payment. Atm we have a (temporarily) limit on the max payment size. With AMP, this can be side stepped as each flow can be up the max size, with the sum of all flows exceeding the max. - Given sufficient path diversity, AMPs may improve the privacy of LN Intermediaries are now unaware to how much of the total payment they are forwarding, or even if they are forwarding a partial payment at all. - Using smaller payments increases the set of possible paths a partial payment could have taken, which reduces the effectiveness of static analysis techniques involving channel capacities and the plaintext values being forwarded. Protocol Overview ================== This design can be seen as a generalization of the single, non-interactive payment scheme, that uses decoding of extra onion blobs (EOBs?) to encode extra data for the receiver. In that design, the extra data includes a payment preimage that the receiver can use to settle back the payment. EOBs and some method of parsing them are really the only requirement for this protocol to work. Thus, only the sender and receiver need to implement this feature in order for it to function, which can be announced using a feature bit. First, let's review the current format of the per-hop payload for each node described in BOLT-0004. ???????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????? ?Realm (1 byte) ?Next Addr (8 bytes)?Amount (8 bytes)?Outgoing CLTV (4 bytes)?Unused (12 bytes)? HMAC (32 bytes) ? ???????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????? ?????????????????????????????????????????????????????? ??????????????????? ?65 Bytes Per Hop ? ??????????????????? Currently, *each* node gets a 65-byte payload. We use this payload to give each node instructions on *how* to forward a payment. We tell each node: the realm (or chain to forward on), then next node to forward to, the amount to forward (this is where fees are extracted by forwarding out less than in), the outgoing CLTV (allows verification that the prior node didn't modify any values), and finally an HMAC over the entire thing. Two important points: 1. We have 12 bytes for each hop that are currently unpurposed and can be used by application protocols to signal new interpretation of bytes and also deliver additional encrypted+authenticated data to *each* hop. 2. The protocol currently has a hard limit of 20-hops. With this feature we ensure that the packet stays fixed sized during processing in order to avoid leaking positional information. Typically most payments won't use all 20 hops, as a result, we can use the remaining hops to stuff in *even more* data. Protocol Description ==================== The solution we propose is Atomic Multi-path Payments (AMPs). At a high level, this leverages EOBs to deliver additive shares of a base preimage, from which the payment preimages of partial payments can be derived. The receiver can only construct this value after having received all of the partial payments, satisfying the atomicity constraint. The basic protocol: Primitives ========== Let H be a CRH function. Let || denote concatenation. Let ^ denote xor. Sender Requirements =================== The parameters to the sending procedure are a random identifier ID, the number of partial payments n, and the total payment value V. Assume the sender has some way of dividing V such that V = v_1 + ? + v_n. To begin, the sender builds the base preimage BP, from which n partial preimages will be derived. Next, the sender samples n additive shares s_1, ?, s_n, and takes the sum to compute BP = s_1 ^ ? ^ s_n. With the base preimage created, the sender now moves on to constructing the n partial payments. For each i in [1,n], the sender deterministically computes the partial preimage r_i = H(BP || i), by concatenating the sequence number i to the base preimage and hashing the result. Afterwards, it applies H to determine the payment hash to use in the i?th partial payment as h_i = H(r_i). Note that that with this preimage derivation scheme, once the payments are pulled each pre-image is distinct and indistinguishable from any other. With all of the pieces in place, the sender initiates the i?th payment by constructing a route to the destination with value v_i and payment hash h_i. The tuple (ID, n, s_i) is included in the EOB to be opened by the receiver. In order to include the three tuple within the per-hop payload for the final destination, we repurpose the _first_ byte of the un-used padding bytes in the payload to signal version 0x01 of the AMP protocol (note this is a PoC outline, we would need to standardize signalling of these 12 bytes to support other protocols). Typically this byte isn't set, so the existence of this means that we're (1) using AMP, and (2) the receiver should consume the _next_ hop as well. So if the payment length is actually 5, the sender tacks on an additional dummy 6th hop, encrypted with the _same_ shared secret for that hop to deliver the e2e encrypted data. Note, the sender can retry partial payments just as they would normal payments, since they are order invariant, and would be indistinguishable from regular payments to intermediaries in the network. Receiver Requirements ===================== Upon the arrival of each partial payment, the receiver will iteratively reconstruct BP, and do some bookkeeping to figure out when to settle the partial payments. During this reconstruction process, the receiver does not need to be aware of the order in which the payments were sent, and in fact nothing about the incoming partial payments reveals this information to the receiver, though this can be learned after reconstructing BP. Each EOB is decoded to retrieve (ID, n, s_i), where i is the unique but unknown index of the incoming partial payment. The receiver has access to persistent key-value store DB that maps ID to (n, c*, BP*), where c* represents the number of partial payments received, BP* is the sum of the received additive shares, and the superscript * denotes that the value is being updated iteratively. c* and BP* both have initial values of 0. In the basic protocol, the receiver cache?s the first n it sees, and verifies that all incoming partial payments have the same n. The receiver should reject all partial payments if any EOB deviates. Next, the we update our persistent store with DB[ID] = (n, c* + 1, BP* ^ s_i), advancing the reconstruction by one step. If c* + 1 < n, there are still more packets in flight, so we sit tight. Otherwise, the receiver assumes all partial payments have arrived, and can being settling them back. Using the base preimage BP = BP* ^ s_i from our final iteration, the receiver can re-derive all n partial preimages and payment hashes, using r_i = H(BP || i) and h_i = H(r_i) simply through knowledge of n and BP. Finally, the receiver settles back any outstanding payments that include payment hash h_i using the partial preimage r_i. Each r_i will appear random due to the nature of H, as will it?s corresponding h_i. Thus, each partial payment should appear uncorrelated, and does not reveal that it is part of an AMP nor the number of partial payments used. Non-interactive to Interactive AMPs =================================== Sender simply receives an ID and amount from the receiver in an invoice before initiating the protocol. The receiver should only consider the invoice settled if the total amount received in partial payments containing ID matches or exceeds the amount specified in the invoice. With this variant, the receiver is able to map all partial payments to a pre-generated invoice statement. Additive Shares vs Threshold-Shares =================================== The biggest reason to use additive shares seems to be atomicity. Threshold shares open the door to some partial payments being settled, even if others are left in flight. Haven?t yet come up with a good reason for using threshold schemes, but there seem to be plenty against it. Reconstruction of additive shares can be done iteratively, and is win for the storage and computation requirements on the receiving end. If the sender decides to use fewer than n partial payments, the remaining shares could be included in the EOB of the final partial payment to allow the sender to reconstruct sooner. Sender could also optimistically do partial reconstruction on this last aggregate value. Adaptive AMPs ============= The sender may not always be aware of how many partial payments they wish to send at the time of the first partial payment, at which point the simplified protocol would require n to be chosen. To accommodate, the above scheme can be adapted to handle a dynamically chosen n by iteratively constructing the shared secrets as follows. Starting with a base preimage BP, the key trick is that the sender remember the difference between the base preimage and the sum of all partial preimages used so far. The relation is described using the following equations: X_0 = 0 X_i = X_{i-1} ^ s_i X_n = BP ^ X_{n-1} where if n=1, X_1 = BP, implying that this is in fact a generalization of the single, non-interactive payment scheme mentioned above. For i=1, ..., n-1, the sender sends s_i in the EOB, and X_n for the n-th share. Iteratively reconstructing s_1 ^ ?. ^ s_{n-1} ^ X_n = BP, allows the receiver to compute all relevant r_i = H(BP || i) and h_i = H(r_i). Lastly, the final number of partial payments n could be signaled in the final EOB, which would also serve as a sentinel value for signaling completion. In response to DOS vectors stemming from unknown values of n, implementations could consider advertising a maximum value for n, or adopting some sort of framing pattern for conveying that more partial payments are on the way. We can further modify our usage of the per-hop payloads to send (H(BP), s_i) to consume most of the EOB sent from sender to receiver. In this scenario, we'd repurpose the 11-bytes *after* our signalling byte in the unused byte section to store the payment ID (which should be unique for each payment). In the case of a non-interactive payment, this will be unused. While for interactive payments, this will be the ID within the invoice. To deliver this slimmer 2-tuple, we'll use 32-bytes for the hash of the BP, and 32-bytes for the partial pre-image share, leaving an un-used byte in the payload. Cross-Chain AMPs ================ AMPs can be used to pay a receiver in multiple currencies atomically...which is pretty cool :D Open Research Questions ======================= The above is a protocol sketch to achieve atomic multi-path payments over Lightning. The details concerning onion blob usage serves as a template that future protocols can draw upon in order to deliver additional data to *any* hop in the route. However, there are still a few open questions before something like this can be feasibly deployed. 1. How does the sender decide how many chunked payments to send, and the size of each payment? - Upon a closer examination, this seems to overlap with the task of congestion control within TCP. The sender may be able to utilize inspired heuristics to gauge: (1) how large the initial payment should be and (2) how many subsequent payments may be required. Note that if the first payment succeeds, then the exchange is over in a signal round. 2. How can AMP and HORNET be composed? - If we eventually integrate HORNET, then a distinct communications sessions can be established to allow the sender+receiver to exchange up-to-date partial payment information. This may allow the sender to more accurately size each partial payment. 3. Can the sender's initial strategy be governed by an instance of the Push-relabel max flow algo? 4. How does this mesh with the current max HTLC limit on a commitment? - ATM, we have a max limit on the number of active HTLC's on a particular commitment transaction. We do this, as otherwise it's possible that the transaction is too large, and exceeds standardness w.r.t transaction size. In a world where most payments use an AMP-like protocol, then overall ant any given instance there will be several pending HTLC's on commitments network wise. This may incentivize nodes to open more channels in order to support the increased commitment space utilization. Conclusion ========== We've presented a design outline of how to integrate atomic multi-path payments (AMP) into Lightning. The existence of such a construct allows a sender to atomically split a payment flow amongst several individual payment flows. As a result, larger channels aren't as important as it's possible to utilize one total outbound payment bandwidth to send several channels. Additionally, in order to support the increased load, internal routing nodes are incensed have more active channels. The existence of AMP-like payments may also increase the longevity of channels as there'll be smaller, more numerous payment flows, making it unlikely that a single payment comes across unbalances a channel entirely. We've also showed how one can utilize the current onion packet format to deliver additional data from a sender to receiver, that's still e2e authenticated. -- Conner && Laolu _______________________________________________ Lightning-dev mailing list Lightning-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -- - Bryan http://heybryan.org/ 1 512 203 0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at jonasschnelli.ch Thu Feb 8 20:22:38 2018 From: dev at jonasschnelli.ch (Jonas Schnelli) Date: Fri, 9 Feb 2018 07:22:38 +1100 Subject: [bitcoin-dev] Electrum Personal Server alpha release In-Reply-To: <8b7bd786-9bc3-efb2-a8ed-0b703e246728@riseup.net> References: <8b7bd786-9bc3-efb2-a8ed-0b703e246728@riseup.net> Message-ID: Thanks Chris for sharing! I?m following a similar approach where I?d like to share a more detailed specification soon. Since Chris brought this up here, I?d like to shed some lights on that, very similar approach. The idea is to have a Bitcoin Core instance running either with internal (Core) support for the proposed interface or via an external script (python bridge) while the later is probably preferable (hardened HTTPd, less impact on Core). The idea is, that the interface can create new wallets (needs dynamic loading/unloading of wallets in Core), add addresses to a wallet (== add watch-only addresses). Addresses on the client are only visible once they could be added via the interface to the Core wallet as watch only (avoid missing transactions, addresses can be pre-added by the client and used later) New transactions can be created through the interface (which will use fundrawtransaction with watch-only-addresses in the background). Coin selection, fee calculation, etc. would happened on the Core node. Signing of transactions happens on the client (maybe BIP174). Optionally, a 2of2 (or 2of3 with a backup key) could be achieved where the node would also hold a key to have some sort of ?2FA? if the node and the client environment are owned by the same person. This would work with pruned nodes and can serve ? depending on the used hardware ? up to a couple of hundred wallets. Backup restores (xpriv sweeps) are also possible via the UTXO set and take less then a minute and don?t require the full transaction history (or any kind of index). Additional, the interface could also act as central, personal multisig bridge where n clients could use the same endpoint to participate in multisig wallets. Overall, this wold allow a slick and secure (personal or group) (multi-)wallet service that works perfectly fine on pruned nodes by simply adding a bridge-script. Thanks ? Jonas > Am 09.02.2018 um 03:51 schrieb Chris Belcher via bitcoin-dev : > > Electrum is a popular bitcoin wallet, but it is not a full node wallet > as it synchronizes itself using third-party Electrum servers. The > servers must be trusted to verify the rules of bitcoin, they can trick > Electrum wallets into accepting fake bitcoin transactions which, for > example, print infinite money. Bitcoin's security model requires that > most economic activity is backed by full nodes. The Electrum servers > must also be trusted with the user's privacy, as wallets send all their > bitcoin addresses to the server. Spying on wallets is not much more > complicated than simply grepping the server logs. Electrum wallets by > default also connect to servers using their own IP address, linking it > further to their revealed bitcoin addresses. > > A way to avoid these problems is for users to run their own Electrum > server and connect their wallets only to it. But this requires > significant resource usage: the full unpruned blockchain, transaction > index and an extra address index, as well as more RAM and CPU usage > compared to just a full node. Servers are not well suited to being shut > down and started up again, they are typically always online. > > Electrum servers store a database of every bitcoin address ever used, > which is inherently not scalable. This is resource-intensive and > therefore pushes users towards centralized solutions. An alternative way > would be to store only your own addresses and transactions. > > Introducing Electrum Personal Server; an implementation of the Electrum > server protocol which fulfills the specific need of using the Electrum > UI with full node verification and privacy, but without the heavyweight > server backend, for a single user. It allows the user to benefit from > all of Bitcoin Core's resource-saving features like pruning, blocksonly > and disabled txindex. All of Electrum's feature-richness like hardware > wallet integration, multisignature wallets, offline signing, mnemonic > recovery phrases and so on can still be used, but backed by the user's > own full node. > > An alpha version of Electrum Personal Server can be found on the > repository: https://github.com/chris-belcher/electrum-personal-server > > Before using, the wallet user must configure Electrum Personal Server > with their master public key and those addresses are imported into > Bitcoin Core as watch-only. If the wallet contains historical > transactions then it must be rescanned. One of Electrum's motivating > features is "instant on", which is therefore traded away when using > Electrum Personal Server in return for full node verification and > privacy. Although if a brand new empty wallet is created there is no > need to rescan. A script like Electrum Personal Server is also well > suited to use private transaction broadcasting tech like dandelion or > broadcasting through tor. > > Using Electrum with Electrum Personal Server is probably the most > resource-efficient way right now to use a hardware wallet connected to > your own full node. People who make use of Blockstream Satellite could > use it to have an off-the-grid node connected to Electrum if that is > their preferred wallet. In the situation of a traveller staying a cheap > hostels, they could sync their node every couple of days to download > recent blocks and use Electrum. Hopefully this software can be part of > the plan to get full node wallets into the hands of as many people as > possible. > > The same kind of ideas could be applied to other lightweight wallets. > For example a full nodes can run on smartphones with pruning and > blocksonly, then a similar script would allow the user to connect their > Samourai Wallet, Breadwallet or GreenAddress app to their own full node. > > > Further Reading: > > * https://bitcointalk.org/index.php?topic=2664747.msg27179198 > * > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015030.html > * https://bitcointalk.org/index.php?topic=1634967.0;all > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From jlrubin at mit.edu Fri Feb 9 07:29:58 2018 From: jlrubin at mit.edu (Jeremy) Date: Thu, 8 Feb 2018 23:29:58 -0800 Subject: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption In-Reply-To: References: Message-ID: This might be unpopular because of bad re-org behavior, but I believe the utility of this construction can be improved if we introduce functionality that makes a script invalid after a certain time (correct me if I'm wrong, I believe all current timelocks are valid after a certain time and invalid before, this is the inverse). Then you can exclude old delegates by timing/block height arguments, or even pre-sign delegates for different periods of time (e.g., if this happens in the next 100 blocks require y, before the next 1000 blocks but after the first 100 require z, etc). -- @JeremyRubin On Mon, Feb 5, 2018 at 11:58 AM, Gregory Maxwell via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant wrote: > > Am I reading correctly that this allows unilateral key rotation (to a > > previously unknown key), without invalidating the interests of other > > parties in the existing multisig (or even requiring any on-chain > > transaction), at the cost of storing the signed delegation? > > Yes, though I'd avoid the word rotation because as you note it doesn't > invalidate the interests of any key, the original setup remains able > to sign. You could allow a new key of yours (plus everyone else) to > sign, assuming the other parties agree... but the old one could also > still sign. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlrubin at mit.edu Fri Feb 9 07:42:52 2018 From: jlrubin at mit.edu (Jeremy) Date: Thu, 8 Feb 2018 23:42:52 -0800 Subject: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption In-Reply-To: References: Message-ID: I'm also highly interested in the case where you sign a delegate conditional on another delegate being signed, e.g. a bilateral agreement. In order for this to work nicely you also need internally something like segwit so that you can refer to one side's delegation by a signature-stable identity. I don't have a suggestion of a nice way to do this at this time, but will stew on it. -- @JeremyRubin On Thu, Feb 8, 2018 at 11:29 PM, Jeremy wrote: > This might be unpopular because of bad re-org behavior, but I believe the > utility of this construction can be improved if we introduce functionality > that makes a script invalid after a certain time (correct me if I'm > wrong, I believe all current timelocks are valid after a certain time and > invalid before, this is the inverse). > > Then you can exclude old delegates by timing/block height arguments, or > even pre-sign delegates for different periods of time (e.g., if this > happens in the next 100 blocks require y, before the next 1000 blocks but > after the first 100 require z, etc). > > > > -- > @JeremyRubin > > > On Mon, Feb 5, 2018 at 11:58 AM, Gregory Maxwell via bitcoin-dev < > bitcoin-dev at lists.linuxfoundation.org> wrote: > >> On Mon, Feb 5, 2018 at 3:56 PM, Ryan Grant >> wrote: >> > Am I reading correctly that this allows unilateral key rotation (to a >> > previously unknown key), without invalidating the interests of other >> > parties in the existing multisig (or even requiring any on-chain >> > transaction), at the cost of storing the signed delegation? >> >> Yes, though I'd avoid the word rotation because as you note it doesn't >> invalidate the interests of any key, the original setup remains able >> to sign. You could allow a new key of yours (plus everyone else) to >> sign, assuming the other parties agree... but the old one could also >> still sign. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jules.lamur at etu.umontpellier.fr Fri Feb 9 13:48:39 2018 From: jules.lamur at etu.umontpellier.fr (Jules Lamur) Date: Fri, 9 Feb 2018 14:48:39 +0100 Subject: [bitcoin-dev] [BIP] Stratum protocol specification Message-ID: Hello, With two student colleagues of mine (Denis HODZHADZHIKOV, Kim-Son PHAM), we are developping a mining pool as an academic work. Currently, most of our work is reverse engineering on existing implementations of the protocol because of the lack of documentation, especially on edge cases. Our referent professor suggested us to publish a IETF RFC draft of the protocol's specification. However, I think a BIP would be more appropriate for this. I've found that the BIP 40 and the BIP 41 were allocated for respectively the wire protocol and the mining protocol since at least August 2013 (cf. https://github.com/bitcoin/bips/commit/e12d37e6639a4acffa2710ddb6cf81e74403b2a1). It seems that nothing has been done since. Could we (me and my colleagues) start writing a draft for the BIP 41 (mining protocol)? Regards, Jules LAMUR. From maxim.solovjov at gmail.com Fri Feb 9 10:55:44 2018 From: maxim.solovjov at gmail.com (Maksim Solovjov) Date: Fri, 9 Feb 2018 12:55:44 +0200 Subject: [bitcoin-dev] Setting up bitcoin dev environment ( bitcoind, bitcoin-cli ) Message-ID: Hi guys, I am trying to set up the bitcoin development environment on my Mac. I installed the Bitcoin Core client ( bitcoin-qt ) and also downloaded the binaries. I face the following issues and hope you can help me to resolve these: 1) Can't open the configuration file from bitcoin-qt. I have a configuration file $HOME/Library/Application Support/Bitcoin/bitcoin.conf but it's empty. When I try to open it via bitcoin-qt ( Preferences -> Show configuration file ) it shows me a popup with an error "Configuration file could not be opened". I tried to change the permissions: "chmod 600"...no luck... 2) I can launch bitcoind in -regtest regime. But when I launch *bitcoin-cli -regtest setgenerate true 101* I get an error: > error code: -32601 > error message: > Method not found 3) If I try *bitcoin-cli getinfo* I get an error: > error: Could not locate RPC credentials. No authentication cookie could be > found, and no rpcpassword is set in the configuration file > (/Users/..../Library/Application Support/Bitcoin/bitcoin.conf) Hope you can help me! Thanks Best, -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitcoin at bpj-code.co.za Fri Feb 9 20:10:25 2018 From: bitcoin at bpj-code.co.za (Bernd Jendrissek) Date: Fri, 9 Feb 2018 22:10:25 +0200 Subject: [bitcoin-dev] Setting up bitcoin dev environment ( bitcoind, bitcoin-cli ) In-Reply-To: References: Message-ID: On 9 February 2018 at 12:55, Maksim Solovjov via bitcoin-dev wrote: > 2) I can launch bitcoind in -regtest regime. > But when I launch bitcoin-cli -regtest setgenerate true 101 > I get an error: >> >> error code: -32601 >> error message: >> Method not found setgenerate was removed in 0.13.0. See doc/release-notes/release-notes-0.13.0.md > 3) If I try bitcoin-cli getinfo > I get an error: >> >> error: Could not locate RPC credentials. No authentication cookie could be >> found, and no rpcpassword is set in the configuration file >> (/Users/..../Library/Application Support/Bitcoin/bitcoin.conf) getinfo is also deprecated or already removed. (Which version did you install?) But even before that, you should probably heed the warning and note that you don't seem to have a bitcoin.conf in a place where bitcoin-cli can find it. From tristan.hoy at gmail.com Mon Feb 12 14:13:11 2018 From: tristan.hoy at gmail.com (Tristan Hoy) Date: Tue, 13 Feb 2018 01:13:11 +1100 Subject: [bitcoin-dev] Transition to post-quantum Message-ID: Hi all, Recently I've been exploring what a post-quantum attack on Bitcoin would actually look like, and what options exist for mitigating it. I've put up a draft of my research here: https://medium.com/@tristanhoy/11271f430c41 In summary: 1) None of the recommended post-quantum DSAs (XMSS, SPHINCS) are scalable 2) This is a rapidly advancing space and committment to a specific post-quantum DSA now would be premature 3) I've identified a strategy (solution 3 in the draft) that mitigates against the worst case scenario (unexpectedly early attack on ECDSA) without requiring any changes to the Bitcoin protocol or total committment to a specific post-quantum DSA that will likely be superseded in the next 3-5 years 4) This strategy also serves as a secure means of transferring balances into a post-quantum DSA address space, even in the event that ECDSA is fully compromised and the transition is reactionary The proposal is a change to key generation only and will be implemented by wallet providers. Feedback would be most appreciated. Regards, Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.ruffing at mmci.uni-saarland.de Mon Feb 12 15:50:50 2018 From: tim.ruffing at mmci.uni-saarland.de (Tim Ruffing) Date: Mon, 12 Feb 2018 16:50:50 +0100 Subject: [bitcoin-dev] Transition to post-quantum In-Reply-To: References: Message-ID: <1518450650.7829.87.camel@mmci.uni-saarland.de> Hi Tristan, Regarding the "Post-Quantum Address Recovery" part (I haven't read the other parts), you may be interested in my message to the list from last month and the rest of the thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015659.html This is an approach which aims to avoid the issues that you've mentioned in your blog post. Best, Tim On Tue, 2018-02-13 at 01:13 +1100, Tristan Hoy via bitcoin-dev wrote: > Hi all, > > Recently I've been exploring what a post-quantum attack on Bitcoin > would actually look like, and what options exist for mitigating it. > > I've put up a draft of my research here: https://medium.com/@tristanh > oy/11271f430c41 > > In summary: > 1) None of the recommended post-quantum DSAs (XMSS, SPHINCS) are > scalable > 2) This is a rapidly advancing space and committment to a specific > post-quantum DSA now would be premature > 3) I've identified a strategy (solution 3 in the draft) that > mitigates against the worst case scenario (unexpectedly early attack > on ECDSA) without requiring any changes to the Bitcoin protocol or > total committment to a specific post-quantum DSA that will likely be > superseded in the next 3-5 years > 4) This strategy also serves as a secure means of transferring > balances into a post-quantum DSA address space, even in the event > that ECDSA is fully compromised and the transition is reactionary > > The proposal is a change to key generation only and will be > implemented by wallet providers. > > Feedback would be most appreciated. > > Regards, > > Tristan > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev From roconnor at blockstream.io Mon Feb 12 15:52:30 2018 From: roconnor at blockstream.io (Russell O'Connor) Date: Mon, 12 Feb 2018 10:52:30 -0500 Subject: [bitcoin-dev] Revisiting BIP 125 RBF policy. Message-ID: I think it is worth revisiting BIP 125's replace-by-fee policy for when to replace transactions. The current policy can be problematic. As noted earlier by Rhavar, sometimes one's transaction becomes pinned making it infeasible to fee bump with RBF. This happens when one makes a normal payment to a large commercial service, and, while the transaction remains unconfirmed, the commercial service creates a low-fee-rate sweep of one's payment, among a collection of others. If one wants to RBF this original payment, for example to get confirmation of the change output for use in further transactions, the current BIP 125 rules require that you make a fee bump that exceeds the combined total fees of the original transaction and the low-fee-rate sweep of the commercial service. The problem is that, while the fee rate of the sweep is low, the absolute size of the fee can still be large, making it infeasible to RBF the original transaction. BIP 125 was defined back in 2015, when perhaps rational miners did care about absolute fee amounts. However, today we are in an era where rational miners care about fee-rates more than absolute fees. The fee-rate of the large sweep transaction is low enough that we do not expect that miners will be mining it in the same block as the original transaction. Today, a rational miner will prefer a fee-bumped version of original transaction without consideration of the low-fee sweep transaction (or at least discounting the low-fee sweep in proportion to the miner's hash-rate fraction). Let me quote the five rules that define the current BIP 125 policy: One or more transactions currently in the mempool (original transactions) > will be replaced by a new transaction (replacement transaction) that spends > one or more of the same inputs if, > > 1. The original transactions signal replaceability explicitly or > through inheritance as described in the above Summary section. > 2. The replacement transaction does not contain any new unconfirmed > inputs that did not previously appear in the mempool. (Unconfirmed inputs > are inputs spending outputs from currently unconfirmed transactions.) > 3. The replacement transaction pays an absolute fee of at least the > sum paid by the original transactions. > 4. The replacement transaction must also pay for its own bandwidth at > or above the rate set by the node's minimum relay fee setting. For example, > if the minimum relay fee is 1 satoshi/byte and the replacement transaction > is 500 bytes total, then the replacement must pay a fee at least 500 > satoshis higher than the sum of the originals. > 5. The number of original transactions to be replaced and their > descendant transactions which will be evicted from the mempool must not > exceed a total of 100 transactions. > > To address the new reality of rational miners' consideration, I propose changing rules 3 and 4 to something like the following. 3'. The replacement transaction pays a fee rate of at least the effective fee rate of any chain of transactions from the set of original transactions that begins with the root of the original transaction set. 4'. The replacement transaction must also pay for replacing the original transactions at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction and the original transactions are 1000 bytes total, then the replacement must pay a fee at least 1000 satoshis higher than the fee of the root transaction of the original transactions. Rule 3' is a fancy way of saying that the replacement transaction must have a fee rate that is larger than the package fee rate of the root of the set of transactions it replaces, where the package fee rate is the fee rate implied by considering CPFP. Rule 4' is an amended anti-spam rule that is intended to avoid DOS attacks from churning the mempool. I don't know if it is really necessary to pay for the size of the original transactions being evicted, but some people I chatted with thought it could be important. Other people on the mailing list have been thinking about RBF policy for far longer than I have, so I wouldn't be surprised if my proposal above is naive. However, I think it can start a conversation about addressing the problems with the current RBF policy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From melvincarvalho at gmail.com Mon Feb 12 17:23:35 2018 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Mon, 12 Feb 2018 18:23:35 +0100 Subject: [bitcoin-dev] Total fees have almost crossed the block reward In-Reply-To: References: Message-ID: On 21 December 2017 at 22:30, Melvin Carvalho wrote: > I asked adam back at hcpp how the block chain would be secured in the long > term, once the reward goes away. The base idea has always been that fees > would replace the block reward. > > At that time fees were approximately 10% of the block reward, but have now > reached 45%, with 50% potentially being crossed soon > > https://fork.lol/reward/feepct > > While this bodes well for the long term security of the coin, I think > there is some legitimate concern that the fee per tx is prohibitive for > some use cases, at this point in the adoption curve. > > Observations of segwit adoption show around 10% at this point > > http://segwit.party/charts/ > > Watching the mempool shows that the congestion is at a peak, though it's > quite possible this will come down over the long weekend. I wonder if this > is of concern to some. > > https://dedi.jochen-hoenicke.de/queue/more/#24h > > I thought these data points may be of interest and are mainly FYI. Though > if further discussion is deemed appropriate, it would be interesting to > hear thoughts. > Just following up on this, for no other reason than I've had my eyes glued to these stats the last few weeks. I'll share a few more stats links. Mempool has come down significantly, as have fees. Tho, of course, this could spike any time. https://bitinfocharts.com/bitcoin/ Typically fees are : $2.06 on tx $543 (median) # 0.38% $3.47 on tx $75,000 (mean) # 0.005% Aside: An observation on this. High value transactors seems to be getting a much better deal, than the mean. This lead me to ponder whether the intuitive metric of satoshi/byte is, in fact, game theory optimal. Possibly over the short term it is, but over a longer period, those wishing to increase the longevity of proof of work in general might wish to consider more progressive fee approaches. Naively, it might be possible to imagine some kind of gaussian distribution that picks tx according to a blended combination of sats/byte and %transacted. Perhaps something for miners and fee estimation algorithms to develop over time. Segwit adoption has increased, and anecdotal evidence shows that trend to continue. The release of 0.16 will I think also have a positive effect. Finally, I came across this wonderful site that shows lightning network adoption on mainnet http://shabang.io/ LN is increasing well. Some blocks are not far off 1% lightning funding, which I think bodes well. I'll go out on a limb and predict that over 1% of btc tx will be lightning based by year end. Since such posts are not strictly development, I'll keep them to a minimum. However, I hope these stats provide useful data points for project evolution. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhavar at protonmail.com Mon Feb 12 17:30:04 2018 From: rhavar at protonmail.com (rhavar at protonmail.com) Date: Mon, 12 Feb 2018 12:30:04 -0500 Subject: [bitcoin-dev] Revisiting BIP 125 RBF policy. In-Reply-To: References: Message-ID: <7zJRAGZXWFiiXu-S3UliZqtP1crDG6s8MDEOurJrXXJc0BkZxw8o0zcGh7DthtvczMxoQHKZ6PwQsZJ0s403noMah26S2xAdGBX2NNL1OfI=@protonmail.com> Thank you very much for writing this up.? It's worth noting that there can be multiple roots for the transactions that are getting replaced. So for rule 3, you probably want a feeRate >= the max "package fee rate" of all replaced roots. I am very happy with this proposal in general, as it's clearly a step in the right direction for making transaction replacement practically usable for todays services. However, I think your new rule 4 is a bit weak. The logical extension of your proposal would be to allow a transaction (say B) be able to replace transactions (say A) by purely paying a higher fee rate, /even if it's less absolute fee/. In this simple example of B replacing A -- B should pay at least: (a.FeeRate * b.size) + relayFeeRate*(a.size + b.size) ?-Ryan ? -------- Original Message -------- On February 12, 2018 10:52 AM, Russell O'Connor via bitcoin-dev wrote: >I think it is worth revisiting BIP 125's replace-by-fee policy for when to replace transactions. >The current policy can be problematic. As noted earlier by Rhavar, sometimes one's transaction becomes pinned making it infeasible to fee bump with RBF.? This happens when one makes a normal payment to a large commercial service, and, while the transaction remains unconfirmed, the commercial service creates a low-fee-rate sweep of one's payment, among a collection of others.? If one wants to RBF this original payment, for example to get confirmation of the change output for use in further transactions, the current BIP 125 rules require that you make a fee bump that exceeds the combined total fees of the original transaction and the low-fee-rate sweep of the commercial service. > >The problem is that, while the fee rate of the sweep is low, the absolute size of the fee can still be large, making it infeasible to RBF the original transaction.? BIP 125 was defined back in 2015, when perhaps rational miners did care about absolute fee amounts. However, today we are in an era where rational miners care about fee-rates more than absolute fees.? The fee-rate of the large sweep transaction is low enough that we do not expect that miners will be mining it in the same block as the original transaction.? Today, a rational miner will prefer a fee-bumped version of original transaction without consideration of the low-fee sweep transaction (or at least discounting the low-fee sweep in proportion to the miner's hash-rate fraction). > >Let me quote the five rules that define the current BIP 125 policy: > >> >>One or more transactions currently in the mempool (original >>transactions) will be replaced by a new transaction (replacement >>transaction) that spends one or more of the same inputs if, >> >> >>1. The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section. >> >>2. The >> replacement transaction does not contain any new unconfirmed inputs >>that did not previously appear in the mempool. (Unconfirmed inputs are >>inputs spending outputs from currently unconfirmed transactions.) >> >>3. The replacement transaction pays an absolute fee of at least the sum paid by the original transactions. >> >>4. The >> replacement transaction must also pay for its own bandwidth at or above >> the rate set by the node's minimum relay fee setting. For example, if >>the minimum relay fee is 1 satoshi/byte and the replacement transaction >>is 500 bytes total, then the replacement must pay a fee at least 500 >>satoshis higher than the sum of the originals. >> >>5. The number of >>original transactions to be replaced and their descendant transactions >>which will be evicted from the mempool must not exceed a total of 100 >>transactions. >> >>To address the new reality of rational miners' consideration, I propose changing rules 3 and 4 to something like the following. >3'. The replacement transaction pays a fee rate of at least the effective fee rate of any chain of transactions from the set of original transactions that begins with the root of the original transaction set. > >4'. The > replacement transaction must also pay for replacing the original transactions at or above > the rate set by the node's minimum relay fee setting. For example, if >the minimum relay fee is 1 satoshi/byte and the replacement transaction and the original transactions are 1000 bytes total, then the replacement must pay a fee at least 1000 >satoshis higher than the fee of the root transaction of the original transactions. >Rule 3' is a fancy way of saying that the replacement transaction must have a fee rate that is larger than the package fee rate of the root of the set of transactions it replaces, where the package fee rate is the fee rate implied by considering CPFP. >Rule 4' is an amended anti-spam rule that is intended to avoid DOS attacks from churning the mempool. I don't know if it is really necessary to pay for the size of the original transactions being evicted, but some people I chatted with thought it could be important. > >Other people on the mailing list have been thinking about RBF policy for far longer than I have, so I wouldn't be surprised if my proposal above is naive.? However, I think it can start a conversation about addressing the problems with the current RBF policy. > From rhavar at protonmail.com Mon Feb 12 17:47:50 2018 From: rhavar at protonmail.com (rhavar at protonmail.com) Date: Mon, 12 Feb 2018 12:47:50 -0500 Subject: [bitcoin-dev] Total fees have almost crossed the block reward In-Reply-To: References: Message-ID: > This lead me to ponder whether the intuitive metric of satoshi/byte is, in fact, game >theory optimal.? Possibly over the short term it is, but over a longer period, those > wishing to increase the longevity of proof of work in general might wish to consider > more progressive fee approaches.? The constraining factor for blocks is the max-block weight. So miners are already optimizing for the right thing (creating a block that gives the most immediate reward). If miners want to start a cartel-like behavior of charging more for more value-transfer it would be incredibly harmful and even likely promote centralization (the cartel would likely not look kindly on any miner who doesn't follow their rules, and perhaps start orphaning their blocks). Now I guess in theory you could add consensus rules that apply restrictions on the amount of "value transfer" in a block, such that miners are motivated to charge more for high-value transactions. However there's going to be almost 0 appetite from anyone to want to do anything like this, and the amount of unintended and harmful side effects would be profound. (Personally, I'd lose any interest in bitcoin if such a change was ever instated) ?-Ryan ? -------- Original Message -------- On February 12, 2018 12:23 PM, Melvin Carvalho via bitcoin-dev wrote: > > >On 21 December 2017 at 22:30, Melvin Carvalho wrote: >>I asked adam back at hcpp how the block chain would be secured in the long term, once the reward goes away.? The base idea has always been that fees would replace the block reward. >>At that time fees were approximately 10% of the block reward, but have now reached 45%, with 50% potentially being crossed soon >> >>https://fork.lol/reward/feepct >> >>While this bodes well for the long term security of the coin, I think there is some legitimate concern that the fee per tx is prohibitive for some use cases, at this point in the adoption curve. >> >>Observations of segwit adoption show around 10% at this point >> >>http://segwit.party/charts/ >> >>Watching the mempool shows that the congestion is at a peak, though it's quite possible this will come down over the long weekend.? I wonder if this is of concern to some. >> >>https://dedi.jochen-hoenicke.de/queue/more/#24h >> >>I thought these data points may be of interest and are mainly FYI.? Though if further discussion is deemed appropriate, it would be interesting to hear thoughts. >> >Just following up on this, for no other reason than I've had my eyes glued to these stats the last few weeks.? I'll share a few more stats links. >Mempool has come down significantly, as have fees.? Tho, of course, this could spike any time.? > >https://bitinfocharts.com/bitcoin/ >Typically fees are : > >?$2.06 on tx $543 (median) # 0.38% >?$3.47 on tx $75,000 (mean) # 0.005% >Aside: An observation on this.? High value transactors seems to be getting a much better deal, than the mean.? This lead me to ponder whether the intuitive metric of satoshi/byte is, in fact, game theory optimal.? Possibly over the short term it is, but over a longer period, those wishing to increase the longevity of proof of work in general might wish to consider more progressive fee approaches.? Naively, it might be possible to imagine some kind of gaussian distribution that picks tx according to a blended combination of sats/byte and %transacted.? Perhaps something for miners and fee estimation algorithms to develop over time. >Segwit adoption has increased, and anecdotal evidence shows that trend to continue.? The release of 0.16 will I think also have a positive effect. >Finally, I came across this wonderful site that shows lightning network adoption on mainnet > >http://shabang.io/ >LN is increasing well.? Some blocks are not far off 1% lightning funding, which I think bodes well.? I'll go out on a limb and predict that over 1% of btc tx will be lightning based by year end. >Since such posts are not strictly development, I'll keep them to a minimum.? However, I hope these stats provide useful data points for project evolution. > > From pete at petertodd.org Mon Feb 12 18:12:32 2018 From: pete at petertodd.org (Peter Todd) Date: Mon, 12 Feb 2018 13:12:32 -0500 Subject: [bitcoin-dev] Total fees have almost crossed the block reward In-Reply-To: References: Message-ID: <20180212181232.GA6489@fedora-23-dvm> On Mon, Feb 12, 2018 at 06:23:35PM +0100, Melvin Carvalho via bitcoin-dev wrote: > Finally, I came across this wonderful site that shows lightning network > adoption on mainnet > > http://shabang.io/ > > LN is increasing well. Some blocks are not far off 1% lightning funding, > which I think bodes well. I'll go out on a limb and predict that over 1% > of btc tx will be lightning based by year end. Does shabang.io say anywhere how it determines whether or not a transaction funded a Lightning channel? -- https://petertodd.org 'peter'[:-1]@petertodd.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From decker.christian at gmail.com Mon Feb 12 19:41:39 2018 From: decker.christian at gmail.com (Christian Decker) Date: Mon, 12 Feb 2018 20:41:39 +0100 Subject: [bitcoin-dev] Total fees have almost crossed the block reward In-Reply-To: <20180212181232.GA6489@fedora-23-dvm> References: <20180212181232.GA6489@fedora-23-dvm> Message-ID: <87bmguvvv0.fsf@gmail.com> Peter Todd via bitcoin-dev writes: > Does shabang.io say anywhere how it determines whether or not a transaction > funded a Lightning channel? My guess they simply collect the short_channel_ids which point to on-chain outputs that funded a channel. This relies on the channels being public, non-public channels can still be identified on settlement. From tristan.hoy at gmail.com Mon Feb 12 21:32:35 2018 From: tristan.hoy at gmail.com (Tristan Hoy) Date: Tue, 13 Feb 2018 08:32:35 +1100 Subject: [bitcoin-dev] Transition to post-quantum In-Reply-To: <1518450650.7829.87.camel@mmci.uni-saarland.de> References: <1518450650.7829.87.camel@mmci.uni-saarland.de> Message-ID: Hi Tim, Just read through your post, thanks for the heads up - I only just joined this mailing list. In a post-quantum world, your second "d" type transaction is completely forgeable, which means it is vulnerable to front-running. An adversary capable of breaking ECDSA needs only listen for these transactions, obtain "classic_sk" and then use a higher fee (or relationship with a miner) to effectively turn your original "d" transaction into a double-spend, with the forged transaction sending all your funds to the adversary. I'm pretty confident that a PQ DSA is required to prevent front-running, and that no "commit-reveal" scheme will be secure without one. The other issue with your approach is that if it is rolled out today, it will effectively double transaction volumes - this is what I tried to solve in solutions 2 and 3 in my article by instead modifying the address generation process. Regards, Tristan On Tue, Feb 13, 2018 at 2:50 AM, Tim Ruffing via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > Hi Tristan, > > Regarding the "Post-Quantum Address Recovery" part (I haven't read the > other parts), you may be interested in my message to the list from last > month and the rest of the thread: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ > 2018-January/015659.html > > This is an approach which aims to avoid the issues that you've > mentioned in your blog post. > > Best, > Tim > > On Tue, 2018-02-13 at 01:13 +1100, Tristan Hoy via bitcoin-dev wrote: > > Hi all, > > > > Recently I've been exploring what a post-quantum attack on Bitcoin > > would actually look like, and what options exist for mitigating it. > > > > I've put up a draft of my research here: https://medium.com/@tristanh > > oy/11271f430c41 > > > > In summary: > > 1) None of the recommended post-quantum DSAs (XMSS, SPHINCS) are > > scalable > > 2) This is a rapidly advancing space and committment to a specific > > post-quantum DSA now would be premature > > 3) I've identified a strategy (solution 3 in the draft) that > > mitigates against the worst case scenario (unexpectedly early attack > > on ECDSA) without requiring any changes to the Bitcoin protocol or > > total committment to a specific post-quantum DSA that will likely be > > superseded in the next 3-5 years > > 4) This strategy also serves as a secure means of transferring > > balances into a post-quantum DSA address space, even in the event > > that ECDSA is fully compromised and the transition is reactionary > > > > The proposal is a change to key generation only and will be > > implemented by wallet providers. > > > > Feedback would be most appreciated. > > > > Regards, > > > > Tristan > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete at petertodd.org Mon Feb 12 22:58:28 2018 From: pete at petertodd.org (Peter Todd) Date: Mon, 12 Feb 2018 17:58:28 -0500 Subject: [bitcoin-dev] Revisiting BIP 125 RBF policy. In-Reply-To: References: Message-ID: <20180212225828.GB8551@fedora-23-dvm> On Mon, Feb 12, 2018 at 10:52:30AM -0500, Russell O'Connor via bitcoin-dev wrote: > I think it is worth revisiting BIP 125's replace-by-fee policy for when to > replace transactions. > > The current policy can be problematic. As noted earlier by Rhavar, > sometimes one's transaction becomes pinned making it infeasible to fee bump > with RBF. This happens when one makes a normal payment to a large > commercial service, and, while the transaction remains unconfirmed, the > commercial service creates a low-fee-rate sweep of one's payment, among a > collection of others. If one wants to RBF this original payment, for > example to get confirmation of the change output for use in further > transactions, the current BIP 125 rules require that you make a fee bump > that exceeds the combined total fees of the original transaction and the > low-fee-rate sweep of the commercial service. > > The problem is that, while the fee rate of the sweep is low, the absolute > size of the fee can still be large, making it infeasible to RBF the > original transaction. BIP 125 was defined back in 2015, when perhaps > rational miners did care about absolute fee amounts. However, today we are > in an era where rational miners care about fee-rates more than absolute > fees. The fee-rate of the large sweep transaction is low enough that we do > not expect that miners will be mining it in the same block as the original > transaction. Today, a rational miner will prefer a fee-bumped version of > original transaction without consideration of the low-fee sweep transaction > (or at least discounting the low-fee sweep in proportion to the miner's > hash-rate fraction). I don't actually see where the problem is here. First of all, suppose we have a transaction T_a that already pays Alice with a feerate sufficiently high that we expect it to get mined in the near future. If we want to pay Bob, we can do that by simply creating a double-spend of T_a that pays both Bob and Alice, T_{ab}. BIP125 only requires that double-spend to have an absolute fee higher than the minimum relay feerate * size of the transaction. I just checked one of my nodes, and the absolute minimum relay fee is about 1/5th that of what estimatefee returns for the longest possible estimate, 48 blocks. Depends on the exact circumstances, but it'll likely be worth it to pay Bob with a replacement of T_a rather than create a second transaction due to that difference. Secondly, if for some reason you need to broadcast a separate transaction paying Bob before you do the replacement, again I don't see an issue: just make a minimum fee T_b that pays Bob, and replace both with T_{ab}. Again, the big difference between minimum fee and what you might actually pay in fees means that you'll still save money in most cases, so long as your wallet is intelligent enough to pick a low feerate for T_b. > Let me quote the five rules that define the current BIP 125 policy: > > One or more transactions currently in the mempool (original transactions) > > will be replaced by a new transaction (replacement transaction) that spends > > one or more of the same inputs if, > > > > 1. The original transactions signal replaceability explicitly or > > through inheritance as described in the above Summary section. > > 2. The replacement transaction does not contain any new unconfirmed > > inputs that did not previously appear in the mempool. (Unconfirmed inputs > > are inputs spending outputs from currently unconfirmed transactions.) > > 3. The replacement transaction pays an absolute fee of at least the > > sum paid by the original transactions. > > 4. The replacement transaction must also pay for its own bandwidth at > > or above the rate set by the node's minimum relay fee setting. For example, > > if the minimum relay fee is 1 satoshi/byte and the replacement transaction > > is 500 bytes total, then the replacement must pay a fee at least 500 > > satoshis higher than the sum of the originals. > > 5. The number of original transactions to be replaced and their > > descendant transactions which will be evicted from the mempool must not > > exceed a total of 100 transactions. > > > > To address the new reality of rational miners' consideration, I propose > changing rules 3 and 4 to something like the following. > > 3'. The replacement transaction pays a fee rate of at least the effective > fee rate of any chain of transactions from the set of original transactions > that begins with the root of the original transaction set. I think what you mean here should be the effective fee rate of the maximum feerate package that can be built from the set of transactions that begins with the candidate replacement. But actually calculating this is I believe non-trivial, which is why I didn't implement it this way when RBF was first implemented. > 4'. The replacement transaction must also pay for replacing the original > transactions at or above the rate set by the node's minimum relay fee > setting. For example, if the minimum relay fee is 1 satoshi/byte and the > replacement transaction and the original transactions are 1000 bytes total, > then the replacement must pay a fee at least 1000 satoshis higher than the > fee of the root transaction of the original transactions. So the previous version of condition #4 does this implicitly because the absolute fee isn't allowed to go down; you're effectively re-adding this condition. But as I've shown above, you can get the same *behavior* by simply ensuring that the transactions you broadcast that you'll want to double-spend have a minimum feerate in the first place. > Rule 3' is a fancy way of saying that the replacement transaction must have > a fee rate that is larger than the package fee rate of the root of the set > of transactions it replaces, where the package fee rate is the fee rate > implied by considering CPFP. > > Rule 4' is an amended anti-spam rule that is intended to avoid DOS attacks > from churning the mempool. I don't know if it is really necessary to pay > for the size of the original transactions being evicted, but some people I > chatted with thought it could be important. I think this is very important. For example, without this condition I could do a DoS attack by repeatedly broadcasting a transaction, then spending the outputs of that transaction with a very large number of child transactions, all of minimum fee. With up to 100 transactions allowed for consideration, and a 100KB max transaction size, that could be up to ~10MB of transactions. Next I double spend the root, increasing it's feerate but *not* paying for the child transactions. Those ~10MB are now evicted from the mempool, and I can repeat the cycle again. The cost is whatever the root tx replacement cost, which will be much less than the cost of broadcasting 10MB should have been. > Other people on the mailing list have been thinking about RBF policy for > far longer than I have, so I wouldn't be surprised if my proposal above is > naive. However, I think it can start a conversation about addressing the > problems with the current RBF policy. A better way to solve this class of problems may be diffed tx replacement propagation: basically broadcast a diff between the original tx and the proposed replacement, allowing you to do the minimum bandwidth accounting based on the size of the diff instead. -- https://petertodd.org 'peter'[:-1]@petertodd.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From roconnor at blockstream.io Mon Feb 12 23:19:40 2018 From: roconnor at blockstream.io (Russell O'Connor) Date: Mon, 12 Feb 2018 18:19:40 -0500 Subject: [bitcoin-dev] Revisiting BIP 125 RBF policy. In-Reply-To: <20180212225828.GB8551@fedora-23-dvm> References: <20180212225828.GB8551@fedora-23-dvm> Message-ID: On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote: > > I don't actually see where the problem is here. First of all, suppose we > have a > transaction T_a that already pays Alice with a feerate sufficiently high > that > we expect it to get mined in the near future. If we want to pay Bob, we > can do > that by simply creating a double-spend of T_a that pays both Bob and Alice, > T_{ab}. BIP125 only requires that double-spend to have an absolute fee > higher > than the minimum relay feerate * size of the transaction. > The problem is that rule 3 of BIP 125 requires you pay a fee that is higher than the the fee of T_a *plus* the fee of the sweep-transaction that the Alice has added as a unconfirmed child transaction to T_a because double-spending to pay Alice and Bob invalidates Alice's sweep-transaction. Alice's sweep-transaction is very large, and hence pays a large absolute fee even though her fee-rate is very low. We do not have any control over its value, hence Alice has "pinned" our RBF transaction. > 3'. The replacement transaction pays a fee rate of at least the effective > > fee rate of any chain of transactions from the set of original > transactions > > that begins with the root of the original transaction set. > > I think what you mean here should be the effective fee rate of the maximum > feerate package that can be built from the set of transactions that begins > with > the candidate replacement. But actually calculating this is I believe > non-trivial, which is why I didn't implement it this way when RBF was first > implemented. > Yes, that is what I mean. My proposal was off-the-mark. Surely CPFP is already computing the package-fee rates of mempool transactions. That is the value we need to compute. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pete at petertodd.org Mon Feb 12 23:42:25 2018 From: pete at petertodd.org (Peter Todd) Date: Mon, 12 Feb 2018 18:42:25 -0500 Subject: [bitcoin-dev] Revisiting BIP 125 RBF policy. In-Reply-To: References: <20180212225828.GB8551@fedora-23-dvm> Message-ID: <20180212234225.GA9131@fedora-23-dvm> On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote: > On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote: > > > > > I don't actually see where the problem is here. First of all, suppose we > > have a > > transaction T_a that already pays Alice with a feerate sufficiently high > > that > > we expect it to get mined in the near future. If we want to pay Bob, we > > can do > > that by simply creating a double-spend of T_a that pays both Bob and Alice, > > T_{ab}. BIP125 only requires that double-spend to have an absolute fee > > higher > > than the minimum relay feerate * size of the transaction. > > > > The problem is that rule 3 of BIP 125 requires you pay a fee that is higher > than the the fee of T_a *plus* the fee of the sweep-transaction that the > Alice has added as a unconfirmed child transaction to T_a because > double-spending to pay Alice and Bob invalidates Alice's > sweep-transaction. Alice's sweep-transaction is very large, and hence pays > a large absolute fee even though her fee-rate is very low. We do not have > any control over its value, hence Alice has "pinned" our RBF transaction. Ah ok, I misunderstood and didn't realise you were talking about the case where Alice re-spends her unconfirmed payment. Unfortunately I don't think that case is possible to solve without putting some kind of restriction on spending unconfirmed outputs; with a restriction it's fairly simple to solve. > > I think what you mean here should be the effective fee rate of the maximum > > feerate package that can be built from the set of transactions that begins > > with > > the candidate replacement. But actually calculating this is I believe > > non-trivial, which is why I didn't implement it this way when RBF was first > > implemented. > > > > Yes, that is what I mean. My proposal was off-the-mark. > > Surely CPFP is already computing the package-fee rates of mempool > transactions. That is the value we need to compute. True, maybe we can just reuse the CPFP calculation now. That said, AFAIK that's only done in the miner code, not the mempool, so that may not be trivial to actually do. -- https://petertodd.org 'peter'[:-1]@petertodd.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From roconnor at blockstream.io Mon Feb 12 23:46:43 2018 From: roconnor at blockstream.io (Russell O'Connor) Date: Mon, 12 Feb 2018 18:46:43 -0500 Subject: [bitcoin-dev] Revisiting BIP 125 RBF policy. In-Reply-To: <20180212234225.GA9131@fedora-23-dvm> References: <20180212225828.GB8551@fedora-23-dvm> <20180212234225.GA9131@fedora-23-dvm> Message-ID: On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote: > On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote: > > On Mon, Feb 12, 2018 at 5:58 PM, Peter Todd wrote: > > > > > > > > I don't actually see where the problem is here. First of all, suppose > we > > > have a > > > transaction T_a that already pays Alice with a feerate sufficiently > high > > > that > > > we expect it to get mined in the near future. If we want to pay Bob, we > > > can do > > > that by simply creating a double-spend of T_a that pays both Bob and > Alice, > > > T_{ab}. BIP125 only requires that double-spend to have an absolute fee > > > higher > > > than the minimum relay feerate * size of the transaction. > > > > > > > The problem is that rule 3 of BIP 125 requires you pay a fee that is > higher > > than the the fee of T_a *plus* the fee of the sweep-transaction that the > > Alice has added as a unconfirmed child transaction to T_a because > > double-spending to pay Alice and Bob invalidates Alice's > > sweep-transaction. Alice's sweep-transaction is very large, and hence > pays > > a large absolute fee even though her fee-rate is very low. We do not > have > > any control over its value, hence Alice has "pinned" our RBF transaction. > > Ah ok, I misunderstood and didn't realise you were talking about the case > where > Alice re-spends her unconfirmed payment. Unfortunately I don't think that > case > is possible to solve without putting some kind of restriction on spending > unconfirmed outputs; with a restriction it's fairly simple to solve. > Adding such a restriction was Rhavar's original suggestion in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688.html, but it seems the proposal wasn't well received because it kinda destroys CPFP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.d.lerner at gmail.com Tue Feb 13 00:54:00 2018 From: sergio.d.lerner at gmail.com (Sergio Demian Lerner) Date: Mon, 12 Feb 2018 21:54:00 -0300 Subject: [bitcoin-dev] [BIP] Stratum protocol specification In-Reply-To: References: Message-ID: When we worked on the extensions for RSK merge mining, I prepared an internal document with the most up to date Straum protocol description I could get. This is the document: https://docs.google.com/document/d/1ocEC8OdFYrvglyXbag1yi8WoskaZoYuR5HGhwf0hWAY/edit?usp=sharing Regards On Fri, Feb 9, 2018 at 10:48 AM, Jules Lamur via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > Hello, > > With two student colleagues of mine (Denis HODZHADZHIKOV, > Kim-Son PHAM), we are developping a mining pool as an > academic work. > > Currently, most of our work is reverse engineering on existing > implementations of the protocol because of the lack of > documentation, especially on edge cases. > > Our referent professor suggested us to publish a IETF RFC draft > of the protocol's specification. However, I think a BIP would be > more appropriate for this. > > I've found that the BIP 40 and the BIP 41 were allocated for > respectively the wire protocol and the mining protocol since > at least August 2013 (cf. > https://github.com/bitcoin/bips/commit/e12d37e6639a4acffa2710ddb6cf81 > e74403b2a1). > > It seems that nothing has been done since. > > Could we (me and my colleagues) start writing a draft for the > BIP 41 (mining protocol)? > > Regards, > Jules LAMUR. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhavar at protonmail.com Mon Feb 12 23:23:12 2018 From: rhavar at protonmail.com (rhavar at protonmail.com) Date: Mon, 12 Feb 2018 18:23:12 -0500 Subject: [bitcoin-dev] Revisiting BIP 125 RBF policy. In-Reply-To: <20180212225828.GB8551@fedora-23-dvm> References: <20180212225828.GB8551@fedora-23-dvm> Message-ID: <0uRiPitofHOu2G_7h4lk1q-BKJOZ_x9UecbP8aqyy7FLlrme06od_H79G7rfIs1uk3Vs470_PSlCHjRqsC9ObqhQRyhZ_9JdEzYJzNd-QRM=@protonmail.com> On February 12, 2018 5:58 PM, Peter Todd via bitcoin-dev wrote: > I don't actually see where the problem is here. First of all, suppose we have a > transaction T_a that already pays Alice with a feerate sufficiently high that > we expect it to get mined in the near future. If we want to pay Bob, we can do > that by simply creating a double-spend of T_a that pays both Bob and Alice, > T_{ab}. BIP125 only requires that double-spend to have an absolute fee higher > than the minimum relay feerate * size of the transaction. It's a bit of a made up term, but when Russel said "pinned" it refers to a child transaction that was made (i.e. in this case by Alice) and for us to replace our transaction we need to "unpin" it. However to unpin it, the current bip125 rules require you pay not only the relay of the transactions you're throwing away, but the absolute fee. This is general is cost prohibitive, as even a normalish transaction can be spending $20 in fees. Also FWIW this whole idea of T_a and T_ab is good, but it's also pretty impractical at the moment due to the sheer amount complexity it introduces (i.e. monitoring, seeing which confirms, trying to rebroadcast the missing one in a way that is safe against reorgs, blah blah). > > I just checked one of my nodes, and the absolute minimum relay fee is about > 1/5th that of what estimatefee returns for the longest possible estimate, 48 > blocks. If you use estimatesmartfee you should be able to get estimates all the way to 1008 or something btw > [...] > I think this is very important. For example, without this condition I could do > a DoS attack by repeatedly broadcasting a transaction, then spending the > outputs of that transaction with a very large number of child transactions, all > of minimum fee. I agree. > > A better way to solve this class of problems may be diffed tx replacement > propagation: basically broadcast a diff between the original tx and the > proposed replacement, allowing you to do the minimum bandwidth accounting based > on the size of the diff instead. This would definitely work for some specific use-case. For instance currently if you do n replacements of a transaction, each time adding an additional output .. you need to pay something like O(n^2) relay fee. If you used a diff instead, you could probably get it to O(n)ish. But relay fee (and n) at the moment, mean it's not a big deal at all. The big flaw (imo) in bip125 is that you need to pay the absolute fee from the transactions you are evicting. And that can be from transactions you didn't even generate yourself. We can already compactly represent the diff (the new transaction invalidates it) the debate is more "Should you have to pay the absolute fee or just relay fee for the stuff you invalidate" From ZmnSCPxj at protonmail.com Tue Feb 13 03:26:47 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 12 Feb 2018 22:26:47 -0500 Subject: [bitcoin-dev] BIP0008 clarification In-Reply-To: <6EAA8D06-3A20-4BBA-BE2E-95B42BCCE7D3@gmail.com> References: <6EAA8D06-3A20-4BBA-BE2E-95B42BCCE7D3@gmail.com> Message-ID: Good morning Helder, >Hi, > > I?m trying to understand the process of signalling and activation of updates in bitcoin. Following BIP34, BIP9, I got into BIP8. > In my understanding of what I read there, an update will be activated even if the threshold of 95% signalling is not reached in STARTED state, as soon as blockchain height is equal or higher than timeout_height. > Is my understanding correct? If so, isn?t it a risk to activate a change even if you don?t have the majority of hash power accepting it? Assuming the update is widespread among economic actors, only miners who do not follow the more stringent rules of the update will suffer, as their blocks will have a high probability of not following those rules and thus will be implicitly rejected by economic actors. Rational miners who follow the update, no matter how small their hash power share, would prefer the chain that economic actors will accept as real and would build only on blocks that follow updated rules strictly. Indeed, the time from STARTED to ACTIVE simply serves to let miners upgrade their software, as a concession that in the real world we cannot safely deploy new software in a single day. Regards, ZmnSCPxj From tim.ruffing at mmci.uni-saarland.de Tue Feb 13 06:46:14 2018 From: tim.ruffing at mmci.uni-saarland.de (Tim Ruffing) Date: Tue, 13 Feb 2018 07:46:14 +0100 Subject: [bitcoin-dev] Transition to post-quantum In-Reply-To: References: <1518450650.7829.87.camel@mmci.uni-saarland.de> Message-ID: <1518504374.9878.24.camel@mmci.uni-saarland.de> On Tue, 2018-02-13 at 08:32 +1100, Tristan Hoy wrote: > In a post-quantum world, your second "d" type transaction is > completely forgeable, which means it is vulnerable to front-running. > An adversary capable of breaking ECDSA needs only listen for these > transactions, obtain "classic_sk" and then use a higher fee (or > relationship with a miner) to effectively turn your original "d" > transaction into a double-spend, with the forged transaction sending > all your funds to the adversary. That's not true. The d(ecommit) transaction, or better let's call it "decommit step" of a two-step transaction does not specify the effects (output script). This is what I denote by "tx" in the writeup, and it's already fixed by the c(ommit) step. So yes, if the user finally reveals d = classic_pk||Sign(classic_sk, tx) a quantum attacker can indeed forge d' = classic_pk||Sign(classic_sk, tx') for tx' != tx of his choice. But that won't help him, because the first valid c step in the chain is for tx and not for tx'. > The other issue with your approach is that if it is rolled out today, > it will effectively double transaction volumes - this is what I tried > to solve in solutions 2 and 3 in my article by instead modifying the > address generation process. Yep, it needs two entries in the blockchain, and that does not mean that it doubles the data. It will need some more bytes in the blockchain but also proper PQ-transactions could need more bytes in the blockchain, so I don't think that's the major issue. > > Regards, > > Tristan > > On Tue, Feb 13, 2018 at 2:50 AM, Tim Ruffing via bitcoin-dev -dev at lists.linuxfoundation.org> wrote: > > Hi Tristan, > > > > Regarding the "Post-Quantum Address Recovery" part (I haven't read > > the > > other parts), you may be interested in my message to the list from > > last > > month and the rest of the thread: > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Januar > > y/015659.html > > > > This is an approach which aims to avoid the issues that you've > > mentioned in your blog post. > > > > Best, > > Tim > > > > On Tue, 2018-02-13 at 01:13 +1100, Tristan Hoy via bitcoin-dev > > wrote: > > > Hi all, > > > > > > Recently I've been exploring what a post-quantum attack on > > Bitcoin > > > would actually look like, and what options exist for mitigating > > it. > > > > > > I've put up a draft of my research here: https://medium.com/@tris > > tanh > > > oy/11271f430c41 > > > > > > In summary: > > > 1) None of the recommended post-quantum DSAs (XMSS, SPHINCS) are > > > scalable > > > 2) This is a rapidly advancing space and committment to a > > specific > > > post-quantum DSA now would be premature > > > 3) I've identified a strategy (solution 3 in the draft) that > > > mitigates against the worst case scenario (unexpectedly early > > attack > > > on ECDSA) without requiring any changes to the Bitcoin protocol > > or > > > total committment to a specific post-quantum DSA that will likely > > be > > > superseded in the next 3-5 years > > > 4) This strategy also serves as a secure means of transferring > > > balances into a post-quantum DSA address space, even in the event > > > that ECDSA is fully compromised and the transition is reactionary > > > > > > The proposal is a change to key generation only and will be > > > implemented by wallet providers. > > > > > > Feedback would be most appreciated. > > > > > > Regards, > > > > > > Tristan > > > _______________________________________________ > > > bitcoin-dev mailing list > > > bitcoin-dev at lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > From tristan.hoy at gmail.com Tue Feb 13 10:06:31 2018 From: tristan.hoy at gmail.com (Tristan Hoy) Date: Tue, 13 Feb 2018 21:06:31 +1100 Subject: [bitcoin-dev] Transition to post-quantum In-Reply-To: <1518504374.9878.24.camel@mmci.uni-saarland.de> References: <1518450650.7829.87.camel@mmci.uni-saarland.de> <1518504374.9878.24.camel@mmci.uni-saarland.de> Message-ID: <882306fa-3ea0-99bd-61c6-f646d27c2ab6@gmail.com> On 13/02/2018 5:46 PM, Tim Ruffing via bitcoin-dev wrote: > On Tue, 2018-02-13 at 08:32 +1100, Tristan Hoy wrote: >> In a post-quantum world, your second "d" type transaction is >> completely forgeable, which means it is vulnerable to front-running. >> An adversary capable of breaking ECDSA needs only listen for these >> transactions, obtain "classic_sk" and then use a higher fee (or >> relationship with a miner) to effectively turn your original "d" >> transaction into a double-spend, with the forged transaction sending >> all your funds to the adversary. > That's not true. The d(ecommit) transaction, or better let's call it > "decommit step" of a two-step transaction does not specify the effects > (output script). This is what I denote by "tx" in the writeup, and it's > already fixed by the c(ommit) step. > > So yes, if the user finally reveals > d = classic_pk||Sign(classic_sk, tx) > a quantum attacker can indeed forge > d' = classic_pk||Sign(classic_sk, tx') > for tx' != tx of his choice. But that won't help him, because the first > valid c step in the chain is for tx and not for tx'. Thank you for clarifying, I should have caught that. >> The other issue with your approach is that if it is rolled out today, >> it will effectively double transaction volumes - this is what I tried >> to solve in solutions 2 and 3 in my article by instead modifying the >> address generation process. > Yep, it needs two entries in the blockchain, and that does not mean > that it doubles the data. It will need some more bytes in the > blockchain but also proper PQ-transactions could need more bytes in the > blockchain, so I don't think that's the major issue. > The worst-case outcome is that ECDSA is broken before PQ addresses are rolled out. There is no reactive response to this - all the existing ECDSA addresses will be compromised. A proactive measure is required, and it should be deployed sooner rather than later. Any two-step approach adopted now as a proactive measure will not only bloat the blockchain, it will also double the effective confirmation time - for all transactions between now and when PQ addresses are rolled out, which seems unlikely to happen in the next 5 years. The bloat will be permanent. Either way, would you mind if I included your approach in the article, with credit? I will seek your review before publishing. >> Regards, >> >> Tristan >> >> On Tue, Feb 13, 2018 at 2:50 AM, Tim Ruffing via bitcoin-dev > -dev at lists.linuxfoundation.org> wrote: >>> Hi Tristan, >>> >>> Regarding the "Post-Quantum Address Recovery" part (I haven't read >>> the >>> other parts), you may be interested in my message to the list from >>> last >>> month and the rest of the thread: >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-Januar >>> y/015659.html >>> >>> This is an approach which aims to avoid the issues that you've >>> mentioned in your blog post. >>> >>> Best, >>> Tim >>> >>> On Tue, 2018-02-13 at 01:13 +1100, Tristan Hoy via bitcoin-dev >>> wrote: >>>> Hi all, >>>> >>>> Recently I've been exploring what a post-quantum attack on >>> Bitcoin >>>> would actually look like, and what options exist for mitigating >>> it. >>>> I've put up a draft of my research here: https://medium.com/@tris >>> tanh >>>> oy/11271f430c41 >>>> >>>> In summary: >>>> 1) None of the recommended post-quantum DSAs (XMSS, SPHINCS) are >>>> scalable >>>> 2) This is a rapidly advancing space and committment to a >>> specific >>>> post-quantum DSA now would be premature >>>> 3) I've identified a strategy (solution 3 in the draft) that >>>> mitigates against the worst case scenario (unexpectedly early >>> attack >>>> on ECDSA) without requiring any changes to the Bitcoin protocol >>> or >>>> total committment to a specific post-quantum DSA that will likely >>> be >>>> superseded in the next 3-5 years >>>> 4) This strategy also serves as a secure means of transferring >>>> balances into a post-quantum DSA address space, even in the event >>>> that ECDSA is fully compromised and the transition is reactionary >>>> >>>> The proposal is a change to key generation only and will be >>>> implemented by wallet providers. >>>> >>>> Feedback would be most appreciated. >>>> >>>> Regards, >>>> >>>> Tristan >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev From jose.femenias at gmail.com Tue Feb 13 12:25:53 2018 From: jose.femenias at gmail.com (=?utf-8?Q?JOSE_FEMENIAS_CA=C3=91UELO?=) Date: Tue, 13 Feb 2018 13:25:53 +0100 Subject: [bitcoin-dev] Possible change to the MIT license Message-ID: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> Hi, Bitcoin is licensed under the MIT license (https://github.com/bitcoin/bitcoin/blob/master/COPYING ) which is one of the most permissive licenses widely in use. While this almost restriction-less license has proved useful to many software projects, I think it could be wise to question its current suitability for this project, given the recent history. The difficulty among the general population to distinguish between Bitcoin (the protocol and software) and bitcoin (the currency) arises spontaneously from the intimate entanglement of both. The current list of Bitcoin lookalikes includes: Bitcoin Cash, Bitcoin Gold, Bitcoin Diamond, Bitcoin God, Bitcoin Clashic, Super Bitcoin, Bitcoin Hot, Bitcoin X, Oil Bitcoin, Bitcoin World, Lightning Bitcoin... This recent flurry of hard forks is, IMHO, exacerbating the confusion about the very nature of the project, and harming it in many ways. Although the liberal MIT license is (rightfully) beneficial to many other projects, companies and individuals, it is my belief that several projects are unfairly taking advantage of this generous license to attack Bitcoin (both the software and the currency), confuse the public, and gain personal profit in a way that is severely harming the Bitcoin ecosystem. Therefore, I?d like to raise the possibility of amending the MIT license in a simple way, by adding a line such as: *** NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN (CORE) BLOCKCHAIN *** (This is just an approximation. A final version would probably have to include a restriction to some soundalikes like BITKOIN, BIITCOIN,?) This way, I could legitimate use this software to create my own crypto coin, or use it in Ethereum, Litecoin or any of the other legitimate cryptos, but I could not make my ?Bitcoin Whatever? fork and keep using this software as the basis for it. I could also fork the bitcoin blockchain to create ?Bcoin lightspeed? but not ?Bitcoin lightspeed? for instance. I know this would probably not prevent the explosion of forks in the future, but maybe it could help mitigate the confusion among the users and the harm to this community. Even if its enforceability is dubious, at least any infringing project would be exposed to some liability. I see myself some possible loopholes the way the license addendum is written. My intention is not to arrive immediately to a final wording but to know if there is some value to the idea of changing the license with this purpose. Jose Femenias From natanael.l at gmail.com Tue Feb 13 14:25:10 2018 From: natanael.l at gmail.com (Natanael) Date: Tue, 13 Feb 2018 15:25:10 +0100 Subject: [bitcoin-dev] Possible change to the MIT license In-Reply-To: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> References: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> Message-ID: Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CA?UELO via bitcoin-dev" < bitcoin-dev at lists.linuxfoundation.org>: *** NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN (CORE) BLOCKCHAIN *** That's better solved with trademarks. (whoever would be the trademark holder - Satoshi?) This would also prohibit any reimplementation that's not formally verified to be perfectly compatible from using the name. It also adds legal uncertainty. Another major problem is that it neither affects anybody forking older versions of Bitcoin, not people using existing independent blockchain implementations and renaming them Bitcoin-Whatsoever. And what happens when an old version is technically incompatible with a future version by the Core team due to not understanding various new softforks? Which version wins the right to the name? Also, being unable to even mention Bitcoin is overkill. The software license also don't affect the blockchain data. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitteaymeric at gmail.com Tue Feb 13 15:22:43 2018 From: vitteaymeric at gmail.com (Aymeric Vitte) Date: Tue, 13 Feb 2018 16:22:43 +0100 Subject: [bitcoin-dev] Possible change to the MIT license In-Reply-To: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> References: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> Message-ID: I was thinking to post something very similar on this list but not sure that it would get some kind of interest Not sure how and if it can be done (ie license modification) but the reuse of the bitcoin core code can allow even a child to launch a fork and this mess should stop, maybe people like to get "free" coins but they are misleaded, they can lose everything and there are some more vicious side effects like replay protection collisions between forks, this is already happening, nobody seems to care but I wrote: Bitcoin Tartuffe, the ultimate fork - User guide: How to create your bitcoin fork in 5mn, fool everybody and become rich https://www.linkedin.com/pulse/user-guide-how-create-your-bitcoin-fork-5mn-fool-everybody-vitte --> this is a parody of course but very close to the reality, some info are intentionally wrong The madness of bitcoin forks: risk, reward and ruin https://www.linkedin.com/pulse/madness-bitcoin-forks-risk-reward-ruin-aymeric-vitte/ I don't think that it really impacts bitcoin itself but this is definitely too easy for people to fork the bitcoin core code and launch some shxtty fork Probably nobody here follow this, as an example (among plenty) see this https://bitcointalk.org/index.php?topic=2515675.msg30173307#msg30173307 completely absurd mess Le 13/02/2018 ? 13:25, JOSE FEMENIAS CA?UELO via bitcoin-dev a ?crit?: > Hi, > > Bitcoin is licensed under the MIT license (https://github.com/bitcoin/bitcoin/blob/master/COPYING ) which is one of the most permissive licenses widely in use. > While this almost restriction-less license has proved useful to many software projects, I think it could be wise to question its current suitability for this project, given the recent history. > > The difficulty among the general population to distinguish between Bitcoin (the protocol and software) and bitcoin (the currency) arises spontaneously from the intimate entanglement of both. > The current list of Bitcoin lookalikes includes: Bitcoin Cash, Bitcoin Gold, Bitcoin Diamond, Bitcoin God, Bitcoin Clashic, Super Bitcoin, Bitcoin Hot, Bitcoin X, Oil Bitcoin, Bitcoin World, Lightning Bitcoin... > > This recent flurry of hard forks is, IMHO, exacerbating the confusion about the very nature of the project, and harming it in many ways. > > Although the liberal MIT license is (rightfully) beneficial to many other projects, companies and individuals, it is my belief that several projects are unfairly taking advantage of this generous license to attack Bitcoin (both the software and the currency), confuse the public, and gain personal profit in a way that is severely harming the Bitcoin ecosystem. > > Therefore, I?d like to raise the possibility of amending the MIT license in a simple way, by adding a line such as: > > > *** > NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN (CORE) BLOCKCHAIN > *** > > (This is just an approximation. A final version would probably have to include a restriction to some soundalikes like BITKOIN, BIITCOIN,?) > > This way, I could legitimate use this software to create my own crypto coin, or use it in Ethereum, Litecoin or any of the other legitimate cryptos, but I could not make my ?Bitcoin Whatever? fork and keep using this software as the basis for it. I could also fork the bitcoin blockchain to create ?Bcoin lightspeed? but not ?Bitcoin lightspeed? for instance. > > I know this would probably not prevent the explosion of forks in the future, but maybe it could help mitigate the confusion among the users and the harm to this community. Even if its enforceability is dubious, at least any infringing project would be exposed to some liability. I see myself some possible loopholes the way the license addendum is written. My intention is not to arrive immediately to a final wording but to know if there is some value to the idea of changing the license with this purpose. > > > Jose Femenias > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms From jameson.lopp at gmail.com Tue Feb 13 15:24:55 2018 From: jameson.lopp at gmail.com (Jameson Lopp) Date: Tue, 13 Feb 2018 10:24:55 -0500 Subject: [bitcoin-dev] Possible change to the MIT license In-Reply-To: References: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> Message-ID: If I'm understanding the problem being stated correctly: "Bitcoin is under a branding attack by fork coins." The proposed solution is to disincentivize fork coins from using the word Bitcoin by altering the license terms. I'm not a lawyer, but it seems to me that the words of the license are basically useless unless there is an entity that intends to make use of court systems to threaten noncompliant projects into submission. In my opinion, the perceived attack on Bitcoin here is social / marketing-based, thus it makes sense that any defense against said attack should also be social / marketing-based. I don't think that Bitcoin should be reliant upon courts or governments to defend itself against attacks of any form. On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > > > Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CA?UELO via bitcoin-dev" < > bitcoin-dev at lists.linuxfoundation.org>: > > *** > NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES > THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS > THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN > (CORE) BLOCKCHAIN > *** > > > That's better solved with trademarks. (whoever would be the trademark > holder - Satoshi?) > > This would also prohibit any reimplementation that's not formally verified > to be perfectly compatible from using the name. > > It also adds legal uncertainty. > > Another major problem is that it neither affects anybody forking older > versions of Bitcoin, not people using existing independent blockchain > implementations and renaming them Bitcoin-Whatsoever. > > And what happens when an old version is technically incompatible with a > future version by the Core team due to not understanding various new > softforks? Which version wins the right to the name? > > Also, being unable to even mention Bitcoin is overkill. > > The software license also don't affect the blockchain data. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitteaymeric at gmail.com Tue Feb 13 15:45:17 2018 From: vitteaymeric at gmail.com (Aymeric Vitte) Date: Tue, 13 Feb 2018 16:45:17 +0100 Subject: [bitcoin-dev] Possible change to the MIT license In-Reply-To: References: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> Message-ID: <267a18b8-707d-8f78-1cff-ba3ed57684c3@gmail.com> No, the problem is not bitcoin being under any kind of attack by the forks for me, but the forks fooling people because, again, reusing the bitcoin core code is too easy I don't know if there can be a legal solution to this which would keep some open source aspect of the code, but at least it deserves to be studied Le 13/02/2018 ? 16:24, Jameson Lopp via bitcoin-dev a ?crit?: > If I'm understanding the problem being stated correctly: > > "Bitcoin is under a branding attack by fork coins." > > The proposed solution is to disincentivize fork coins from using the > word Bitcoin by altering the license terms. I'm not a lawyer, but it > seems to me that the words of the license are basically useless unless > there is an entity that intends to make use of court systems to > threaten noncompliant projects into submission. > > In my opinion, the perceived attack on Bitcoin here is social / > marketing-based, thus it makes sense that any defense against said > attack should also be social / marketing-based. I don't think that > Bitcoin should be reliant upon courts or governments to defend itself > against attacks of any form. > > On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev > > wrote: > > > > Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CA?UELO via > bitcoin-dev" >: > > *** > NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT > THAT USES THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS > MARKETING MATERIAL UNLESS THE SOFTWARE PRODUCED BY THAT > PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN (CORE) BLOCKCHAIN > *** > > > That's better solved with trademarks. (whoever would be the > trademark holder - Satoshi?)?? > > This would also prohibit any reimplementation that's not formally > verified to be perfectly compatible from using the name.? > > It also adds legal uncertainty.? > > Another major problem is that it neither affects anybody forking > older versions of Bitcoin, not people using existing independent > blockchain implementations and renaming them Bitcoin-Whatsoever.? > > And what happens when an old version is technically incompatible > with a future version by the Core team due to not understanding > various new softforks? Which version wins the right to the name?? > > Also, being unable to even mention Bitcoin is overkill.? > > The software license also don't affect the blockchain data.? > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions Zcash wallets made simple: https://github.com/Ayms/zcash-wallets Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets Get the torrent dynamic blocklist: http://peersm.com/getblocklist Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameson.lopp at gmail.com Tue Feb 13 15:45:55 2018 From: jameson.lopp at gmail.com (Jameson Lopp) Date: Tue, 13 Feb 2018 10:45:55 -0500 Subject: [bitcoin-dev] Possible change to the MIT license In-Reply-To: References: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> Message-ID: Anyone who feels so inclined is free to "pick up the mantle" and defend Bitcoin against perceived social attacks. I don't think that Bitcoin protocol developers have any particular responsibility to do so, and as such this particular discussion is likely going to quickly veer off-topic for this mailing list. On Tue, Feb 13, 2018 at 10:37 AM, Brian Lockhart wrote: > > I don't think that Bitcoin should be reliant upon courts or governments > to defend itself against attacks of any form. > > Agree 100%. Plus yeah, lotsa luck getting any success via those channels... > > But assuming the answer to the perceived problem is to ?fight fire with > fire? (using social / marketing based efforts) who ?should? pick up the > mantle here? Without inciting riots by asking the question, wouldn?t that > ostensibly be something the Bitcoin Foundation would lead on here? and runs for cover> > > In any case, it?s frustrating to watch the ongoing FUD and scammery going > unanswered in any ?official? capacity. > > > On February 13, 2018 at 7:25:35 AM, Jameson Lopp via bitcoin-dev ( > bitcoin-dev at lists.linuxfoundation.org) wrote: > > If I'm understanding the problem being stated correctly: > > "Bitcoin is under a branding attack by fork coins." > > The proposed solution is to disincentivize fork coins from using the word > Bitcoin by altering the license terms. I'm not a lawyer, but it seems to me > that the words of the license are basically useless unless there is an > entity that intends to make use of court systems to threaten noncompliant > projects into submission. > > In my opinion, the perceived attack on Bitcoin here is social / > marketing-based, thus it makes sense that any defense against said attack > should also be social / marketing-based. I don't think that Bitcoin should > be reliant upon courts or governments to defend itself against attacks of > any form. > > On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev < > bitcoin-dev at lists.linuxfoundation.org> wrote: > >> >> >> Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CA?UELO via bitcoin-dev" < >> bitcoin-dev at lists.linuxfoundation.org>: >> >> *** >> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES >> THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS >> THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN >> (CORE) BLOCKCHAIN >> *** >> >> >> That's better solved with trademarks. (whoever would be the trademark >> holder - Satoshi?) >> >> This would also prohibit any reimplementation that's not formally >> verified to be perfectly compatible from using the name. >> >> It also adds legal uncertainty. >> >> Another major problem is that it neither affects anybody forking older >> versions of Bitcoin, not people using existing independent blockchain >> implementations and renaming them Bitcoin-Whatsoever. >> >> And what happens when an old version is technically incompatible with a >> future version by the Core team due to not understanding various new >> softforks? Which version wins the right to the name? >> >> Also, being unable to even mention Bitcoin is overkill. >> >> The software license also don't affect the blockchain data. >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bedriguler at gmail.com Tue Feb 13 15:47:09 2018 From: bedriguler at gmail.com (Bedri Ozgur Guler) Date: Tue, 13 Feb 2018 18:47:09 +0300 Subject: [bitcoin-dev] Possible change to the MIT license In-Reply-To: References: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> Message-ID: Hello, The use of name Bitcoin cannot be avoided due to it's nature of being a Protocol. Prohibition of usage of it as a "brand name" is just like prohibiting the word "Linux", which is the name of the kernel, being used as a brand name or part of a brand name. If that had happened, systems based on Linux kernel couldn't have used Linux word in their brands. The licence in the Linux example is GPL but it does not really differ so much. Making a protocol name a Trademark(TM) name and prohibiting it's use may solve some confusions and bad reputation causing actions but it also prohibits the protocol to be used widely so damages the credibility of the protocol itself which was born to be an independent, freedom-based, government-free, boundaries-free etc. approach to the current corrupted monetary system. If precautions should be taken to control the usage of Bitcoin word in various positions and cases, it should be done in such a way that it should not contradict with the philosophy of the Bitcoin itself. Social /marketing-based approaches proposed by Jameson Lopp will be more logical and freedom based. Trademarking and in some sense Cartel-ing the Bitcoin Protocol who arose against trademarks and cartels on "money" will destroy it's own roots and birth-right of existence in my opinion. Bedri ?zg?r G?ler On Tue, Feb 13, 2018 at 6:24 PM, Jameson Lopp via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > If I'm understanding the problem being stated correctly: > > "Bitcoin is under a branding attack by fork coins." > > The proposed solution is to disincentivize fork coins from using the word > Bitcoin by altering the license terms. I'm not a lawyer, but it seems to me > that the words of the license are basically useless unless there is an > entity that intends to make use of court systems to threaten noncompliant > projects into submission. > > In my opinion, the perceived attack on Bitcoin here is social / > marketing-based, thus it makes sense that any defense against said attack > should also be social / marketing-based. I don't think that Bitcoin should > be reliant upon courts or governments to defend itself against attacks of > any form. > > On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev < > bitcoin-dev at lists.linuxfoundation.org> wrote: > >> >> >> Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CA?UELO via bitcoin-dev" < >> bitcoin-dev at lists.linuxfoundation.org>: >> >> *** >> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES >> THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS >> THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN >> (CORE) BLOCKCHAIN >> *** >> >> >> That's better solved with trademarks. (whoever would be the trademark >> holder - Satoshi?) >> >> This would also prohibit any reimplementation that's not formally >> verified to be perfectly compatible from using the name. >> >> It also adds legal uncertainty. >> >> Another major problem is that it neither affects anybody forking older >> versions of Bitcoin, not people using existing independent blockchain >> implementations and renaming them Bitcoin-Whatsoever. >> >> And what happens when an old version is technically incompatible with a >> future version by the Core team due to not understanding various new >> softforks? Which version wins the right to the name? >> >> Also, being unable to even mention Bitcoin is overkill. >> >> The software license also don't affect the blockchain data. >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brianlockhart at gmail.com Tue Feb 13 15:37:09 2018 From: brianlockhart at gmail.com (Brian Lockhart) Date: Tue, 13 Feb 2018 07:37:09 -0800 Subject: [bitcoin-dev] Possible change to the MIT license In-Reply-To: References: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> Message-ID: > I don't think that Bitcoin should be reliant upon courts or governments to defend itself against attacks of any form. Agree 100%. Plus yeah, lotsa luck getting any success via those channels... But assuming the answer to the perceived problem is to ?fight fire with fire? (using social / marketing based efforts) who ?should? pick up the mantle here? Without inciting riots by asking the question, wouldn?t that ostensibly be something the Bitcoin Foundation would lead on here? In any case, it?s frustrating to watch the ongoing FUD and scammery going unanswered in any ?official? capacity. On February 13, 2018 at 7:25:35 AM, Jameson Lopp via bitcoin-dev ( bitcoin-dev at lists.linuxfoundation.org) wrote: If I'm understanding the problem being stated correctly: "Bitcoin is under a branding attack by fork coins." The proposed solution is to disincentivize fork coins from using the word Bitcoin by altering the license terms. I'm not a lawyer, but it seems to me that the words of the license are basically useless unless there is an entity that intends to make use of court systems to threaten noncompliant projects into submission. In my opinion, the perceived attack on Bitcoin here is social / marketing-based, thus it makes sense that any defense against said attack should also be social / marketing-based. I don't think that Bitcoin should be reliant upon courts or governments to defend itself against attacks of any form. On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > > > Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CA?UELO via bitcoin-dev" < > bitcoin-dev at lists.linuxfoundation.org>: > > *** > NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES > THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS > THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN > (CORE) BLOCKCHAIN > *** > > > That's better solved with trademarks. (whoever would be the trademark > holder - Satoshi?) > > This would also prohibit any reimplementation that's not formally verified > to be perfectly compatible from using the name. > > It also adds legal uncertainty. > > Another major problem is that it neither affects anybody forking older > versions of Bitcoin, not people using existing independent blockchain > implementations and renaming them Bitcoin-Whatsoever. > > And what happens when an old version is technically incompatible with a > future version by the Core team due to not understanding various new > softforks? Which version wins the right to the name? > > Also, being unable to even mention Bitcoin is overkill. > > The software license also don't affect the blockchain data. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ bitcoin-dev mailing list bitcoin-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.murck at gmail.com Tue Feb 13 17:04:48 2018 From: patrick.murck at gmail.com (Patrick Murck) Date: Tue, 13 Feb 2018 12:04:48 -0500 Subject: [bitcoin-dev] Possible change to the MIT license In-Reply-To: References: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> Message-ID: This is a poor idea, and agree that it?s largely off-topic. So without wasting too much of anyone?s time here, I?d point out the following. It is pretty clear that any developer who is subject to a lawsuit from someone using Bitcoin Core software could point to the license (among other things) *defensively* to limit their liability. But who would be in a position to assert an *offensive* claim that their license terms have been breached? Who would have a right in the software that they are granting via the license? Definitely not the Bitcoin Foundation? This software is meant to be free and open for anyone to use, unfortunately that means some people will sometimes do things you disagree with. -pm On February 13, 2018 at 11:24:37 AM, Brian Lockhart via bitcoin-dev ( bitcoin-dev at lists.linuxfoundation.org) wrote: > I don't think that Bitcoin should be reliant upon courts or governments to defend itself against attacks of any form. Agree 100%. Plus yeah, lotsa luck getting any success via those channels... But assuming the answer to the perceived problem is to ?fight fire with fire? (using social / marketing based efforts) who ?should? pick up the mantle here? Without inciting riots by asking the question, wouldn?t that ostensibly be something the Bitcoin Foundation would lead on here? In any case, it?s frustrating to watch the ongoing FUD and scammery going unanswered in any ?official? capacity. On February 13, 2018 at 7:25:35 AM, Jameson Lopp via bitcoin-dev ( bitcoin-dev at lists.linuxfoundation.org) wrote: If I'm understanding the problem being stated correctly: "Bitcoin is under a branding attack by fork coins." The proposed solution is to disincentivize fork coins from using the word Bitcoin by altering the license terms. I'm not a lawyer, but it seems to me that the words of the license are basically useless unless there is an entity that intends to make use of court systems to threaten noncompliant projects into submission. In my opinion, the perceived attack on Bitcoin here is social / marketing-based, thus it makes sense that any defense against said attack should also be social / marketing-based. I don't think that Bitcoin should be reliant upon courts or governments to defend itself against attacks of any form. On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > > > Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CA?UELO via bitcoin-dev" < > bitcoin-dev at lists.linuxfoundation.org>: > > *** > NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES > THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS > THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN > (CORE) BLOCKCHAIN > *** > > > That's better solved with trademarks. (whoever would be the trademark > holder - Satoshi?) > > This would also prohibit any reimplementation that's not formally verified > to be perfectly compatible from using the name. > > It also adds legal uncertainty. > > Another major problem is that it neither affects anybody forking older > versions of Bitcoin, not people using existing independent blockchain > implementations and renaming them Bitcoin-Whatsoever. > > And what happens when an old version is technically incompatible with a > future version by the Core team due to not understanding various new > softforks? Which version wins the right to the name? > > Also, being unable to even mention Bitcoin is overkill. > > The software license also don't affect the blockchain data. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > _______________________________________________ bitcoin-dev mailing list bitcoin-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.ficsor73 at gmail.com Tue Feb 13 17:25:50 2018 From: adam.ficsor73 at gmail.com (Adam Ficsor) Date: Tue, 13 Feb 2018 18:25:50 +0100 Subject: [bitcoin-dev] Possible change to the MIT license Message-ID: I agree with the opposition on changing the license, because of the branding attacks. However having two coins with the same Proof Of Work is a zero sum game from a security point of view. It may not be a bad idea to consider changing the license in a way that only limits cryptocurrencies with the same Proof Of Work, since they directly affect the stability and security of Bitcoin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danrobinson010 at gmail.com Tue Feb 13 17:46:18 2018 From: danrobinson010 at gmail.com (Daniel Robinson) Date: Tue, 13 Feb 2018 17:46:18 +0000 Subject: [bitcoin-dev] Possible change to the MIT license In-Reply-To: References: Message-ID: Custom open-source licenses are basically never a good idea. Every deviation in wording from universally-accepted open-source licensing terms is a major compliance headache from the perspective of any organization trying to use the software. You don?t want users having to clear their use of Bitcoin Core through their employers? legal departments, whether or not they would ultimately approve that use. For that reason alone I think such a change is not viable, no matter how you phrased it. On Tue, Feb 13, 2018 at 9:27 AM Adam Ficsor via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > I agree with the opposition on changing the license, because of the > branding attacks. > > However having two coins with the same Proof Of Work is a zero sum game > from a security point of view. It may not be a bad idea to consider > changing the license in a way that only limits cryptocurrencies with the > same Proof Of Work, since they directly affect the stability and security > of Bitcoin. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luke at dashjr.org Tue Feb 13 17:53:40 2018 From: luke at dashjr.org (Luke Dashjr) Date: Tue, 13 Feb 2018 17:53:40 +0000 Subject: [bitcoin-dev] Possible change to the MIT license In-Reply-To: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> References: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> Message-ID: <201802131753.41846.luke@dashjr.org> This would give too much power to Bitcoin Core, and implies falsely that Bitcoin and Bitcoin Core are the same thing. On Tuesday 13 February 2018 12:25:53 PM JOSE FEMENIAS CA?UELO via bitcoin-dev wrote: > Hi, > > Bitcoin is licensed under the MIT license > (https://github.com/bitcoin/bitcoin/blob/master/COPYING > ) which is one of > the most permissive licenses widely in use. While this almost > restriction-less license has proved useful to many software projects, I > think it could be wise to question its current suitability for this > project, given the recent history. > > The difficulty among the general population to distinguish between Bitcoin > (the protocol and software) and bitcoin (the currency) arises > spontaneously from the intimate entanglement of both. The current list of > Bitcoin lookalikes includes: Bitcoin Cash, Bitcoin Gold, Bitcoin Diamond, > Bitcoin God, Bitcoin Clashic, Super Bitcoin, Bitcoin Hot, Bitcoin X, Oil > Bitcoin, Bitcoin World, Lightning Bitcoin... > > This recent flurry of hard forks is, IMHO, exacerbating the confusion about > the very nature of the project, and harming it in many ways. > > Although the liberal MIT license is (rightfully) beneficial to many other > projects, companies and individuals, it is my belief that several projects > are unfairly taking advantage of this generous license to attack Bitcoin > (both the software and the currency), confuse the public, and gain > personal profit in a way that is severely harming the Bitcoin ecosystem. > > Therefore, I?d like to raise the possibility of amending the MIT license in > a simple way, by adding a line such as: > > > *** > NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES THE > NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS THE > SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN > (CORE) BLOCKCHAIN *** > > (This is just an approximation. A final version would probably have to > include a restriction to some soundalikes like BITKOIN, BIITCOIN,?) > > This way, I could legitimate use this software to create my own crypto > coin, or use it in Ethereum, Litecoin or any of the other legitimate > cryptos, but I could not make my ?Bitcoin Whatever? fork and keep using > this software as the basis for it. I could also fork the bitcoin > blockchain to create ?Bcoin lightspeed? but not ?Bitcoin lightspeed? for > instance. > > I know this would probably not prevent the explosion of forks in the > future, but maybe it could help mitigate the confusion among the users and > the harm to this community. Even if its enforceability is dubious, at > least any infringing project would be exposed to some liability. I see > myself some possible loopholes the way the license addendum is written. My > intention is not to arrive immediately to a final wording but to know if > there is some value to the idea of changing the license with this purpose. > > > Jose Femenias > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev From felix.wolfsteller at gmail.com Tue Feb 13 17:28:58 2018 From: felix.wolfsteller at gmail.com (Felix Wolfsteller) Date: Tue, 13 Feb 2018 18:28:58 +0100 Subject: [bitcoin-dev] Possible change to the MIT license In-Reply-To: References: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> Message-ID: <3b30d56c-9f3d-578b-3982-edbeb37ee7c7@gmail.com> I'd call the license change an attack on bitcoin if its code license prohibited me to play around with it and call it whatever I the fud I want. Other entities like companies, goverments and whoknowswhat might prohibit that (in some countries of the world), but the nature of the source and protocoll shall be Free (as in free speech). Even if my code changes are compatible with the current blockchain as per bitcoin core I would have the lifetime "threat" that one day my code wouldnt anymore because of changes in bitcoin core, and I wouldnt like to get letters from lawyers earning their money by sending out letters. Besides I am not fully sure if I could sign the main assumption that the forks "... [are] exacerbating the confusion about the very nature of the project, and harming it in many ways." Or at least I am not sure that the "harm done" __in the end__ is bigger than the gains and the proof-of-spirit as well as all the insights gained through what happens here, regarding Free (well, MIT) Software out in the world. Yes, its not always pleasant but I think its worth it. -f On 13.02.2018 16:47, Bedri Ozgur Guler via bitcoin-dev wrote: > Hello, > The use of name Bitcoin cannot be avoided due to it's nature of being a > Protocol. Prohibition of usage of it as a "brand name" is just like > prohibiting the word "Linux", which is the name of the kernel, being used > as a brand name or part of a brand name. If that had happened, systems > based on Linux kernel couldn't have used Linux word in their brands. The > licence in the Linux example is GPL but it does not really differ so much. > Making a protocol name a Trademark(TM) name and prohibiting it's use may > solve some confusions and bad reputation causing actions but it also > prohibits the protocol to be used widely so damages the credibility of the > protocol itself which was born to be an independent, freedom-based, > government-free, boundaries-free etc. approach to the current corrupted > monetary system. > > If precautions should be taken to control the usage of Bitcoin word in > various positions and cases, it should be done in such a way that it should > not contradict with the philosophy of the Bitcoin itself. Social > /marketing-based approaches proposed by Jameson Lopp will be more logical > and freedom based. Trademarking and in some sense Cartel-ing the Bitcoin > Protocol who arose against trademarks and cartels on "money" will destroy > it's own roots and birth-right of existence in my opinion. > > Bedri ?zg?r G?ler > > On Tue, Feb 13, 2018 at 6:24 PM, Jameson Lopp via bitcoin-dev < > bitcoin-dev at lists.linuxfoundation.org> wrote: > >> If I'm understanding the problem being stated correctly: >> >> "Bitcoin is under a branding attack by fork coins." >> >> The proposed solution is to disincentivize fork coins from using the word >> Bitcoin by altering the license terms. I'm not a lawyer, but it seems to me >> that the words of the license are basically useless unless there is an >> entity that intends to make use of court systems to threaten noncompliant >> projects into submission. >> >> In my opinion, the perceived attack on Bitcoin here is social / >> marketing-based, thus it makes sense that any defense against said attack >> should also be social / marketing-based. I don't think that Bitcoin should >> be reliant upon courts or governments to defend itself against attacks of >> any form. >> >> On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev < >> bitcoin-dev at lists.linuxfoundation.org> wrote: >> >>> >>> >>> Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CA?UELO via bitcoin-dev" < >>> bitcoin-dev at lists.linuxfoundation.org>: >>> >>> *** >>> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES >>> THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS >>> THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN >>> (CORE) BLOCKCHAIN >>> *** >>> >>> >>> That's better solved with trademarks. (whoever would be the trademark >>> holder - Satoshi?) >>> >>> This would also prohibit any reimplementation that's not formally >>> verified to be perfectly compatible from using the name. >>> >>> It also adds legal uncertainty. >>> >>> Another major problem is that it neither affects anybody forking older >>> versions of Bitcoin, not people using existing independent blockchain >>> implementations and renaming them Bitcoin-Whatsoever. >>> >>> And what happens when an old version is technically incompatible with a >>> future version by the Core team due to not understanding various new >>> softforks? Which version wins the right to the name? >>> >>> Also, being unable to even mention Bitcoin is overkill. >>> >>> The software license also don't affect the blockchain data. >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > From pete at petertodd.org Tue Feb 13 18:40:34 2018 From: pete at petertodd.org (Peter Todd) Date: Tue, 13 Feb 2018 13:40:34 -0500 Subject: [bitcoin-dev] Revisiting BIP 125 RBF policy. In-Reply-To: <0uRiPitofHOu2G_7h4lk1q-BKJOZ_x9UecbP8aqyy7FLlrme06od_H79G7rfIs1uk3Vs470_PSlCHjRqsC9ObqhQRyhZ_9JdEzYJzNd-QRM=@protonmail.com> References: <20180212225828.GB8551@fedora-23-dvm> <0uRiPitofHOu2G_7h4lk1q-BKJOZ_x9UecbP8aqyy7FLlrme06od_H79G7rfIs1uk3Vs470_PSlCHjRqsC9ObqhQRyhZ_9JdEzYJzNd-QRM=@protonmail.com> Message-ID: <20180213184034.GA10642@fedora-23-dvm> On Mon, Feb 12, 2018 at 06:23:12PM -0500, rhavar at protonmail.com wrote: > > On February 12, 2018 5:58 PM, Peter Todd via bitcoin-dev wrote: > > > I don't actually see where the problem is here. First of all, suppose we have a > > transaction T_a that already pays Alice with a feerate sufficiently high that > > we expect it to get mined in the near future. If we want to pay Bob, we can do > > that by simply creating a double-spend of T_a that pays both Bob and Alice, > > T_{ab}. BIP125 only requires that double-spend to have an absolute fee higher > > than the minimum relay feerate * size of the transaction. > > It's a bit of a made up term, but when Russel said "pinned" it refers to a child transaction that was made (i.e. in this case by Alice) and for us to replace our transaction we need to "unpin" it. Yeah, sorry, I just misread what scenario you guys were talking about. IIRC the term "pinned" may have even been invented by myself, as IIRC I noticed the issue when the RBF patch was being developed years ago. I don't think I had a solution at the time so I just punted on it. > However to unpin it, the current bip125 rules require you pay not only the relay of the transactions you're throwing away, but the absolute fee. This is general is cost prohibitive, as even a normalish transaction can be spending $20 in fees. > > Also FWIW this whole idea of T_a and T_ab is good, but it's also pretty impractical at the moment due to the sheer amount complexity it introduces (i.e. monitoring, seeing which confirms, trying to rebroadcast the missing one in a way that is safe against reorgs, blah blah). I'm not sure that's actually true, as you're only creating transactions sets that are reorg safe. Though I don't have a detailed design in mind so I may be missing something. > > A better way to solve this class of problems may be diffed tx replacement > > propagation: basically broadcast a diff between the original tx and the > > proposed replacement, allowing you to do the minimum bandwidth accounting based > > on the size of the diff instead. > > This would definitely work for some specific use-case. For instance currently if you do n replacements of a transaction, each time adding an additional output .. you need to pay something like O(n^2) relay fee. If you used a diff instead, you could probably get it to O(n)ish. > > But relay fee (and n) at the moment, mean it's not a big deal at all. The big flaw (imo) in bip125 is that you need to pay the absolute fee from the transactions you are evicting. And that can be from transactions you didn't even generate yourself. We can already compactly represent the diff (the new transaction invalidates it) the debate is more "Should you have to pay the absolute fee or just relay fee for the stuff you invalidate" Yes, the diff approach doesn't help for the pinned case. Unfortunately the only solution I have is basically the same as what you proposed(1) months ago: limit spends of unconfirmed outputs in some way. So here's a question: how many wallets have actually implemented CPFP fee bumps for incoming transactions? 1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688.html -- https://petertodd.org 'peter'[:-1]@petertodd.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From pete at petertodd.org Tue Feb 13 19:03:17 2018 From: pete at petertodd.org (Peter Todd) Date: Tue, 13 Feb 2018 14:03:17 -0500 Subject: [bitcoin-dev] Total fees have almost crossed the block reward In-Reply-To: <87bmguvvv0.fsf@gmail.com> References: <20180212181232.GA6489@fedora-23-dvm> <87bmguvvv0.fsf@gmail.com> Message-ID: <20180213190317.GA10931@fedora-23-dvm> On Mon, Feb 12, 2018 at 08:41:39PM +0100, Christian Decker wrote: > Peter Todd via bitcoin-dev > writes: > > Does shabang.io say anywhere how it determines whether or not a transaction > > funded a Lightning channel? > > My guess they simply collect the short_channel_ids which point to > on-chain outputs that funded a channel. This relies on the channels > being public, non-public channels can still be identified on settlement. Sounds plausible; it'd be good if they documented that on the site! -- https://petertodd.org 'peter'[:-1]@petertodd.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From lists at coryfields.com Tue Feb 13 19:08:02 2018 From: lists at coryfields.com (Cory Fields) Date: Tue, 13 Feb 2018 14:08:02 -0500 Subject: [bitcoin-dev] Possible change to the MIT license In-Reply-To: <3b30d56c-9f3d-578b-3982-edbeb37ee7c7@gmail.com> References: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> <3b30d56c-9f3d-578b-3982-edbeb37ee7c7@gmail.com> Message-ID: I agree that this is a bad idea. When trying to work around a social issue for a highly technical project, a legal hack is certainly not the answer. As Daniel pointed out, the result of such a change would simply be that 100% of all Bitcoin companies would be told by their legal teams to use the last MIT-licensed version of Bitcoin Core as they would have no idea how to prove that they're not in violation. So I think it would succeed in exactly the _opposite_ of its intended purpose. As Patrick said: > This software is meant to be free and open for anyone to use, unfortunately that means some people will sometimes do things you disagree with. Bitcoin is a Kleenex, a Q-Tip, a Xerox in the crypto world. I think we should just accept that as a feature at this point. Let other projects faff about with copyright litigation and trademark dilution concerns :) Besides, I assume many/most developers would be unwilling to accept such a change. Speaking for only myself at least, I would not contribute under that license. I must admit, though, that it would be fun to read codified No-True-Scotsman appeals in a software license :p. Cory On Tue, Feb 13, 2018 at 12:28 PM, Felix Wolfsteller via bitcoin-dev wrote: > I'd call the license change an attack on bitcoin if its code license > prohibited me to play around with it and call it whatever I the fud I want. > Other entities like companies, goverments and whoknowswhat might > prohibit that (in some countries of the world), but the nature of the > source and protocoll shall be Free (as in free speech). > > Even if my code changes are compatible with the current blockchain as > per bitcoin core I would have the lifetime "threat" that one day my code > wouldnt anymore because of changes in bitcoin core, and I wouldnt like > to get letters from lawyers earning their money by sending out letters. > > Besides I am not fully sure if I could sign the main assumption that the > forks "... [are] exacerbating the confusion about the very nature of the > project, and harming it in many ways." > Or at least I am not sure that the "harm done" __in the end__ is bigger > than the gains and the proof-of-spirit as well as all the insights > gained through what happens here, regarding Free (well, MIT) Software > out in the world. Yes, its not always pleasant but I think its worth it. > > -f > > > On 13.02.2018 16:47, Bedri Ozgur Guler via bitcoin-dev wrote: >> Hello, >> The use of name Bitcoin cannot be avoided due to it's nature of being a >> Protocol. Prohibition of usage of it as a "brand name" is just like >> prohibiting the word "Linux", which is the name of the kernel, being used >> as a brand name or part of a brand name. If that had happened, systems >> based on Linux kernel couldn't have used Linux word in their brands. The >> licence in the Linux example is GPL but it does not really differ so much. >> Making a protocol name a Trademark(TM) name and prohibiting it's use may >> solve some confusions and bad reputation causing actions but it also >> prohibits the protocol to be used widely so damages the credibility of the >> protocol itself which was born to be an independent, freedom-based, >> government-free, boundaries-free etc. approach to the current corrupted >> monetary system. >> >> If precautions should be taken to control the usage of Bitcoin word in >> various positions and cases, it should be done in such a way that it should >> not contradict with the philosophy of the Bitcoin itself. Social >> /marketing-based approaches proposed by Jameson Lopp will be more logical >> and freedom based. Trademarking and in some sense Cartel-ing the Bitcoin >> Protocol who arose against trademarks and cartels on "money" will destroy >> it's own roots and birth-right of existence in my opinion. >> >> Bedri ?zg?r G?ler >> >> On Tue, Feb 13, 2018 at 6:24 PM, Jameson Lopp via bitcoin-dev < >> bitcoin-dev at lists.linuxfoundation.org> wrote: >> >>> If I'm understanding the problem being stated correctly: >>> >>> "Bitcoin is under a branding attack by fork coins." >>> >>> The proposed solution is to disincentivize fork coins from using the word >>> Bitcoin by altering the license terms. I'm not a lawyer, but it seems to me >>> that the words of the license are basically useless unless there is an >>> entity that intends to make use of court systems to threaten noncompliant >>> projects into submission. >>> >>> In my opinion, the perceived attack on Bitcoin here is social / >>> marketing-based, thus it makes sense that any defense against said attack >>> should also be social / marketing-based. I don't think that Bitcoin should >>> be reliant upon courts or governments to defend itself against attacks of >>> any form. >>> >>> On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev < >>> bitcoin-dev at lists.linuxfoundation.org> wrote: >>> >>>> >>>> >>>> Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CA?UELO via bitcoin-dev" < >>>> bitcoin-dev at lists.linuxfoundation.org>: >>>> >>>> *** >>>> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES >>>> THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS >>>> THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN >>>> (CORE) BLOCKCHAIN >>>> *** >>>> >>>> >>>> That's better solved with trademarks. (whoever would be the trademark >>>> holder - Satoshi?) >>>> >>>> This would also prohibit any reimplementation that's not formally >>>> verified to be perfectly compatible from using the name. >>>> >>>> It also adds legal uncertainty. >>>> >>>> Another major problem is that it neither affects anybody forking older >>>> versions of Bitcoin, not people using existing independent blockchain >>>> implementations and renaming them Bitcoin-Whatsoever. >>>> >>>> And what happens when an old version is technically incompatible with a >>>> future version by the Core team due to not understanding various new >>>> softforks? Which version wins the right to the name? >>>> >>>> Also, being unable to even mention Bitcoin is overkill. >>>> >>>> The software license also don't affect the blockchain data. >>>> >>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev From cryptaxe at gmail.com Tue Feb 13 19:08:36 2018 From: cryptaxe at gmail.com (CryptAxe) Date: Tue, 13 Feb 2018 11:08:36 -0800 Subject: [bitcoin-dev] Possible change to the MIT license In-Reply-To: <3b30d56c-9f3d-578b-3982-edbeb37ee7c7@gmail.com> References: <65F92B37-48C1-4CD5-8F17-47BF9BD231A9@gmail.com> <3b30d56c-9f3d-578b-3982-edbeb37ee7c7@gmail.com> Message-ID: This is ridiculous. We shouldn't bastardize open source principals because someone hurt your feelings. This is how open source works, stop using it if you don't like it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhavar at protonmail.com Wed Feb 14 02:07:25 2018 From: rhavar at protonmail.com (rhavar at protonmail.com) Date: Tue, 13 Feb 2018 21:07:25 -0500 Subject: [bitcoin-dev] Revisiting BIP 125 RBF policy. In-Reply-To: <20180213184034.GA10642@fedora-23-dvm> References: <20180212225828.GB8551@fedora-23-dvm> <0uRiPitofHOu2G_7h4lk1q-BKJOZ_x9UecbP8aqyy7FLlrme06od_H79G7rfIs1uk3Vs470_PSlCHjRqsC9ObqhQRyhZ_9JdEzYJzNd-QRM=@protonmail.com> <20180213184034.GA10642@fedora-23-dvm> Message-ID: On February 13, 2018 1:40 PM, Peter Todd wrote: > Yeah, sorry, I just misread what scenario you guys were talking about. IIRC the > term "pinned" may have even been invented by myself, as IIRC I noticed the > issue when the RBF patch was being developed years ago. I don't think I had a > solution at the time so I just punted on it. Yeah. I posted that before it was clarified, it's just my message got held up in the moderation queue so it came out of order at an inconvenient time >< > I'm not sure that's actually true, as you're only creating transactions sets > that are reorg safe. Though I don't have a detailed design in mind so I may be > missing something. It is. T_a and T_ab are "reorg" safe, but if T_a confirms you will still need to pay Bob in way. But you need to pay him such that in a reorg occurs and suddenly T_ab is mined, you haven't doubled paid him. I've been working on it's implementation, but it's honestly really complex and hard to test. I outlined the procedure here: https://gist.github.com/RHavar/cff76a026ece8446c898470db4f35682 which I call "Super Withdrawals". My point though isn't that it's impossible, it's that it's sufficiently complex that it's unreasonable to expect anyone to be doing it any time soon. By relaxing any unnecessary restrictions on bip125, just makes it _drastically_ easier to do certain things. > So here's a question: how many wallets have actually implemented CPFP fee bumps > for incoming transactions? Never tried it, but I recall seeing it in the electrum gui. I originally tried supporting this myself, but it's kind of annoying. It's generally a bit cost-prohibitive to create a transaction specifically for the purpose of a CPFP fee bump, but since I made transactions pretty frequently (averaged say every 8 minutes) it doesn't add an additional input for the purpose of bumping selected incoming transactions. The work flow is reasonably smooth: Alice has sent me 1 BTC with low fees, I owe Bob some money. I source Alice's output in the payment to Bob, giving her transaction a fee bump. Both transactions confirm, everyone is happy. However during the whole time I need to watch Alice's transaction because if it ever is replaced/conflicted, I need to immediately pay Bob (in a reorg safe way, so I don't double-pay). It's not terribly hard to do, by making sure when I pay Bob I use an additional input that I also use for any "repayment" but it's enough complexity and hard enough to test that I gave up. The really nice thing of most current send systems (and now especially so with segwit) is everything is pretty much fire and forget. (although I just schedule in 0.5, 1, 2, 4, .... 32 hours fee bump attempts. But that's just background that can fail/succeed blindly) > >1. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014688.html > > -- >https://petertodd.org 'peter'[:-1]@petertodd.org > > From roconnor at blockstream.io Wed Feb 14 14:08:01 2018 From: roconnor at blockstream.io (Russell O'Connor) Date: Wed, 14 Feb 2018 09:08:01 -0500 Subject: [bitcoin-dev] Revisiting BIP 125 RBF policy. In-Reply-To: <20180212234225.GA9131@fedora-23-dvm> References: <20180212225828.GB8551@fedora-23-dvm> <20180212234225.GA9131@fedora-23-dvm> Message-ID: On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote: > On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote: > > Surely CPFP is already computing the package-fee rates of mempool > > transactions. That is the value we need to compute. > > True, maybe we can just reuse the CPFP calculation now. That said, AFAIK > that's > only done in the miner code, not the mempool, so that may not be trivial to > actually do. > Do you (or anyone else) know if the package fee rate is considered when ejecting transactions from the bottom of the mempool when the mempool gets too large? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gsanders87 at gmail.com Wed Feb 14 14:16:29 2018 From: gsanders87 at gmail.com (Greg Sanders) Date: Wed, 14 Feb 2018 09:16:29 -0500 Subject: [bitcoin-dev] Revisiting BIP 125 RBF policy. In-Reply-To: References: <20180212225828.GB8551@fedora-23-dvm> <20180212234225.GA9131@fedora-23-dvm> Message-ID: Yes. On Wed, Feb 14, 2018 at 9:08 AM, Russell O'Connor via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote: > >> On Mon, Feb 12, 2018 at 06:19:40PM -0500, Russell O'Connor wrote: >> > Surely CPFP is already computing the package-fee rates of mempool >> > transactions. That is the value we need to compute. >> >> True, maybe we can just reuse the CPFP calculation now. That said, AFAIK >> that's >> only done in the miner code, not the mempool, so that may not be trivial >> to >> actually do. >> > > Do you (or anyone else) know if the package fee rate is considered when > ejecting transactions from the bottom of the mempool when the mempool gets > too large? > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From willtech at live.com.au Wed Feb 14 10:09:25 2018 From: willtech at live.com.au (Damian Williamson) Date: Wed, 14 Feb 2018 10:09:25 +0000 Subject: [bitcoin-dev] Possible change to the MIT license Message-ID: I do not know that Bitcoin's position is any weaker because of the terms that the software is licenced under. Cory Fields said: >Let other projects faff about with copyright litigation and trademark dilution concerns I disagree completely with any licence change. As well as allowing for the use of a software, a licence is also a disclaimer for those responsible for the release. Changing a single word can have drastic implications should there ever be any action considered against any involved party or group. The current MIT licence is IMHO the right fit. Regards, Damian Williamson -------------- next part -------------- An HTML attachment was scrubbed... URL: From falke.marco at gmail.com Wed Feb 14 22:01:46 2018 From: falke.marco at gmail.com (Marco Falke) Date: Wed, 14 Feb 2018 17:01:46 -0500 Subject: [bitcoin-dev] Amend the BIP 123 process to include buried deployments Message-ID: I define a buried deployment as a consensus rule change that affects validity of blocks that are buried by a sufficiently large number of blocks in the current valid most-work chain, but the current block (and all its parents) remain valid. BIP 123 suggests that BIPs in the consensus layer should be assigned a label "soft fork" or "hard fork". However, I think the differentiation into soft fork or hard fork should not be made for BIPs that document buried deployments. In contrast to soft forks and hard forks, buried deployments do not require community and miner coordination for a safe deployment. For a chain fork to happen due to a buried deployment, a massive chain reorganization must be produced off of a block in the very past. In the extremely unlikely event of such a large chain reorganization, Bitcoin's general security assumptions would be violated regardless of the presence of a buried deployment. From luke at dashjr.org Wed Feb 14 22:11:42 2018 From: luke at dashjr.org (Luke Dashjr) Date: Wed, 14 Feb 2018 22:11:42 +0000 Subject: [bitcoin-dev] Amend the BIP 123 process to include buried deployments In-Reply-To: References: Message-ID: <201802142211.44293.luke@dashjr.org> On Wednesday 14 February 2018 10:01:46 PM Marco Falke via bitcoin-dev wrote: > BIP 123 suggests that BIPs in the consensus layer should be assigned a > label "soft fork" or "hard fork". However, I think the differentiation > into soft fork or hard fork should not be made for BIPs that document > buried deployments. In contrast to soft forks and hard forks, buried > deployments do not require community and miner coordination for a safe > deployment. They also do not require software coordination. Therefore, why should there be BIPs at all? Seems to me that we should instead add these documents to https://github.com/bitcoin-core/docs That being said, I'm also okay with just adding an Annex to the original softfork/hardfork BIP describing each shortcut. It just seems annoying to have two BIPs for every protocol change: one for the change itself, and then another for implementation-specific shortcuts taken. Luke From greg at xiph.org Wed Feb 14 22:20:31 2018 From: greg at xiph.org (Gregory Maxwell) Date: Wed, 14 Feb 2018 22:20:31 +0000 Subject: [bitcoin-dev] Amend the BIP 123 process to include buried deployments In-Reply-To: <201802142211.44293.luke@dashjr.org> References: <201802142211.44293.luke@dashjr.org> Message-ID: On Wed, Feb 14, 2018 at 10:11 PM, Luke Dashjr via bitcoin-dev wrote: > On Wednesday 14 February 2018 10:01:46 PM Marco Falke via bitcoin-dev wrote: >> BIP 123 suggests that BIPs in the consensus layer should be assigned a >> label "soft fork" or "hard fork". However, I think the differentiation >> into soft fork or hard fork should not be made for BIPs that document >> buried deployments. In contrast to soft forks and hard forks, buried >> deployments do not require community and miner coordination for a safe >> deployment. > > They also do not require software coordination. Therefore, why should there be > BIPs at all? Seems to me that we should instead add these documents to > https://github.com/bitcoin-core/docs In that sense, no but they help people understand the system (e.g. so they don't go look at implementations and confuse that the activations they expect are simply not there); and they aid other implementations in understanding what other people have already analyzed and concluded was safe. You could certainly get an analysis wrong for one of these things. From eric at voskuil.org Wed Feb 14 23:57:10 2018 From: eric at voskuil.org (Eric Voskuil) Date: Wed, 14 Feb 2018 15:57:10 -0800 Subject: [bitcoin-dev] Amend the BIP 123 process to include buried deployments In-Reply-To: References: Message-ID: <8fb2e424-268c-7433-5f6b-5fbab5c5cc5c@voskuil.org> On 02/14/2018 02:01 PM, Marco Falke via bitcoin-dev wrote: > I define a buried deployment as a consensus rule change that affects > validity of blocks that are buried by a sufficiently large number of > blocks in the current valid most-work chain, Sufficient for what, specifically? > but the current block (and all its parents) remain valid. Remain valid in the case where the depth assumption is "sufficient" to ensure that a chain split is not possible? If this was true (which it is not), it would imply that there is no reason to validate any block deeper than the most recent 25,000. Presumably this means that people may continuously rely on some authority (like Bitcoin Core?) to determine the checkpoint for tip-25,000. > BIP 123 suggests that BIPs in the consensus layer should be assigned a > label "soft fork" or "hard fork". However, I think the differentiation > into soft fork or hard fork should not be made for BIPs that document > buried deployments. In contrast to soft forks and hard forks, buried > deployments do not require community and miner coordination for a safe > deployment. They can only avoid this requirement based on the assumption that the hard fork cannot result in a chain split. This is not the case. > For a chain fork to happen due to a buried deployment, a massive chain > reorganization must be produced off of a block in the very past. In other words a "buried deployment" is a hard fork that is not likely to cause a chain split. This is a subjective subcategory of hard fork, not an independent category - unless maybe you can show that there is the 25,000 blocks number is an objective threshold. > In the extremely unlikely event of such a large chain reorganization, > Bitcoin's general security assumptions would be violated regardless of > the presence of a buried deployment. This is untrue. The "security assumptions" of Bitcoin do not preclude deep reorganizations. e -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From tim.ruffing at mmci.uni-saarland.de Thu Feb 15 15:59:27 2018 From: tim.ruffing at mmci.uni-saarland.de (Tim Ruffing) Date: Thu, 15 Feb 2018 16:59:27 +0100 Subject: [bitcoin-dev] Transition to post-quantum In-Reply-To: <882306fa-3ea0-99bd-61c6-f646d27c2ab6@gmail.com> References: <1518450650.7829.87.camel@mmci.uni-saarland.de> <1518504374.9878.24.camel@mmci.uni-saarland.de> <882306fa-3ea0-99bd-61c6-f646d27c2ab6@gmail.com> Message-ID: <1518710367.3550.111.camel@mmci.uni-saarland.de> First of all, there is indeed an issue in my proposal: The idea was to include a classic signature to make sure that, if (for whatever reason) you have revealed classic_pk already. However, the problem is that if you have revealed classic_pk, then everybody can effectively prevent you from spending the funds as you wish by just including the first commit entry with an arbitrary tx in the blockchain. That's bad obviously. Here is a fixed variant, which does not only work with normal P2PKH but 1) supports basically with any (hash-based) addresses, for which the preimage has not been revealed and 2) does not change the conditions under which a UTXO can be spent. Setup ===== We will need multiple hash functions KDF, H, and authenticated symmetric encryption Enc/Dec. Let's assume we have an UTXO with address addr = H_addr(chal), where chal is a challenge, i.e., typically a scriptPubKey (what I called classic_pk initially) and H_addr is the hash function used to form addresses. (If there are multiple UTXO sharing the same address, they can be spent simultaneously with this approach.) To spend this UTXO with a transaction tx, the user performs the following two steps. Note that -- in contrast to my earlier emails -- tx is assumed to include a solution to the challenge in its input, i.e., a string which proves that you are allowed to spend the UTXO (typically a scriptSig). Commit step =========== Derive a symmetric key k = KDF(chal). Create and publish a commitment in the blockchain that references the UTXO as inputs and contains the following data: c = Enc(k, tx) Wait until c is confirmed. (If it does not confirm, send it again as usual.) Decommit step ============= Create and publish a decommitment with the following data: d = chal Consensus rules =============== A decommitment d = chal spends a UTXO with address H_addr(chal), if there exists a commitment c in the blockchain which references the UTXO and which is the first commitment (among all referencing the UTXO) in the blockchain such that 1. k = KDF(chal) correctly decrypts Dec(k, c) and 2. tx = Dec(k, c) is a valid transaction to spend UTXO The UTXO is spent as described by tx. Commitments never expire. The second condition covers that tx contains a classic signature under the public key specified in chal in normal P2PKH addresses. The trick here is that the encryption ensures that the user commits to tx (including the classic signature) already in the commit step, while still keeping the decommitment unique. If I'm not mistaken, this scheme is a variant of Adam Back's proposal for committed transactions from 2013, which he invented for an entirely different goal, namely censorship resistance: https://bitcointalk.org/index.php?topic=206303.msg2162962#msg2162962 (Adam noted the similarity of the problems on Twitter recently: https://twitter.com/adam3us/status/948219461345075201) The above variant is pretty simple. If it really works and is secure, it has the advantage over Adam's proposal that it does not rely on ECDSA specifically and can be used for any address type. The aforementioned thread in the Bitcoin forum discusses the main problem of an approach like that: Everybody can flood the blockchain with commitments. Of course, one can require fees to create commitments, but that's pretty ugly: If this UTXO is the only money you have, then you need to borrow some to pay the transaction fees upfront. But this may be the price you need to pay for recovery. This can be acceptable, because recovery should be the exception (see below). On Tue, 2018-02-13 at 21:06 +1100, Tristan Hoy via bitcoin-dev wrote: > The worst-case outcome is that ECDSA is broken before PQ addresses > are > rolled out. There is no reactive response to this - all the existing > ECDSA addresses will be compromised. A proactive measure is > required, > and it should be deployed sooner rather than later. The proposal above does not require any changes to existing ECDSA addresses, so there is no need to change something now already. At some point in the future, PQ addresses will be deployed. And at some (potentially different) point in the future, we should deploy a solution to recover UTXOs. But there's no need to do this today. A recovery solution can be deployed even when DLOG has been broken already -- not optimal but possible. > > Any two-step approach adopted now as a proactive measure will not > only > bloat the blockchain, it will also double the effective confirmation > time - for all transactions between now and when PQ addresses are > rolled > out, which seems unlikely to happen in the next 5 years. The bloat > will > be permanent. > I don't think that's true due to the situation I describe above. We don't need to act now. And even if we act now, i.e., even if we enable the above proposal (or any other protocol that enables recovery of UTXOs with addresses) today, people are not forced to use it. As long as ECDSA and the other schemes we use today remain secure, people can and will continue to perform conventional transactions. Ideally, people will need a recovery protocol only for those UTXOs which they haven't touched for years and have forgotten to convert to PQ in time. You mentioned confirmation time. A nice thing is that the above protocol does not double confirmation times. The sender needs to wait for confirmation of the commitment. But as soon as the commitment is confirmed, double-spending is excluded already, because the sender is committed to the transaction. So the recipient does not need to wait for confirmation of the decommitment. As soon as the recipient sees the decommitment, everything is good. (If the decommitment is not confirmed, the recipient can just re-broadcast it.) In practice, we could even go further and call the transaction done after the commitment is confirmed and the sender sends the data for the second step to the recipient off-chain. Only when the recipient wants to spend the funds again, the recipient will reveal this data. The fact that double-spending is excluded after the first step is confirmed, is exactly what makes the protocol secure against quantum attackers who want to steal the money. As soon as the user reveals the ECDSA public key, a quantum attacker has access to all secrets: The attacker knows the preimage of the hash can compute the secret key. So from this point on, there is no hope that we can distinguish the honest user from the attacker. But since the correct transaction has been committed to the blockchain, and cannot be changed anymore, we don't need to distinguish the honest user from the attacker. > Either way, would you mind if I included your approach in the > article, > with credit? I will seek your review before publishing. Sure, feel free to include. You don't need to seek my review but I can certainly have a look if desired. Tim From natanael.l at gmail.com Thu Feb 15 20:27:27 2018 From: natanael.l at gmail.com (Natanael) Date: Thu, 15 Feb 2018 21:27:27 +0100 Subject: [bitcoin-dev] Transition to post-quantum In-Reply-To: <1518710367.3550.111.camel@mmci.uni-saarland.de> References: <1518450650.7829.87.camel@mmci.uni-saarland.de> <1518504374.9878.24.camel@mmci.uni-saarland.de> <882306fa-3ea0-99bd-61c6-f646d27c2ab6@gmail.com> <1518710367.3550.111.camel@mmci.uni-saarland.de> Message-ID: Den 15 feb. 2018 17:00 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev at lists.linuxfoundation.org>: Consensus rules =============== A decommitment d = chal spends a UTXO with address H_addr(chal), if there exists a commitment c in the blockchain which references the UTXO and which is the first commitment (among all referencing the UTXO) in the blockchain such that 1. k = KDF(chal) correctly decrypts Dec(k, c) and 2. tx = Dec(k, c) is a valid transaction to spend UTXO The UTXO is spent as described by tx. Commitments never expire. I addressed this partially before, and this is unfortunately incomplete. Situation A: Regardless of expiration of commitments, we allow doubles. (Or no doubles allowed, but commitments expire.) If I can block your transaction from confirming (censorship), then I can make my own commitment + transaction. The miners will see two commitments referencing the same UTXO - but can see only one transaction which match a valid challenge and spends them, which is mine. You gained nothing from the commitment. Situation B: We don't allow conflicting commitments, and they never expire. I can now freeze everybody's funds trivially with invalid commitments, because you can't validate a commitment without seeing a valid transaction matching it - and exposing an uncommitted transaction breaks the security promise of commitments. Any additional data in the commitment but hash it the transaction is pointless, because the security properties are the same. You can't freeze an UTXO after only seeing a commitment, and for any two conflicting transactions you may observe it does not matter at all if one references UTXO:s or not since you already know both transactions' commitment ages anyway. Oldest would win no matter the additional data. Commitments work when the network can't easily be censored for long enough to deploy the attack (at least for 2-3 blocks worth of time). They fail when the attacker is capable of performing such an attack. As I said previously, the only completely solid solution in all circumstances is a quantum resistant Zero-knowledge proof algorithm, or some equivalent method of proving knowledge of the key without revealing any data that enables a quantum attack. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.ruffing at mmci.uni-saarland.de Thu Feb 15 21:57:41 2018 From: tim.ruffing at mmci.uni-saarland.de (Tim Ruffing) Date: Thu, 15 Feb 2018 22:57:41 +0100 Subject: [bitcoin-dev] Transition to post-quantum In-Reply-To: References: <1518450650.7829.87.camel@mmci.uni-saarland.de> <1518504374.9878.24.camel@mmci.uni-saarland.de> <882306fa-3ea0-99bd-61c6-f646d27c2ab6@gmail.com> <1518710367.3550.111.camel@mmci.uni-saarland.de> Message-ID: <1518731861.3550.131.camel@mmci.uni-saarland.de> On Thu, 2018-02-15 at 21:27 +0100, Natanael wrote: > I addressed this partially before, and this is unfortunately > incomplete. > > Situation A: Regardless of expiration of commitments, we allow > doubles. (Or no doubles allowed, but commitments expire.) > > If I can block your transaction from confirming (censorship), then I > can make my own commitment + transaction. The miners will see two > commitments referencing the same UTXO - but can see only one > transaction which match a valid challenge and spends them, which is > mine. You gained nothing from the commitment. Yes, I assume situation A: * commitments never expire * and there is no limit on the number of commitment for the same UTXO As I understand, you mean "decommitment" when you say "transaction". Please correct me if I'm wrong. I'll stick with "decommitment". Let's assume the attacker blocks the decommitment by the honest user, inserts his own malicious commitment and his own decommitment, which should be valid for the malicious commitment. Then the miners will see two commitments (the earlier commitment by the honest user and the later one by the attacker). Also, the miners will indeed see one valid decommitment. This decommitment may have been sent by the attacker but it's the preimage chal of the address, because otherwise it's not valid for the malicious commitment. But if the decommitment is chal, then this decommitment is also valid for the commitment of the honest user, which is earliest additionally. So the honest commitment wins. The attacker does not succeed and everything is fine. The reason why this works: There is only one unique decommitment for the UTXO (assuming H_addr is collision-resistant). The decommitment does not depend on the commitment. The attacker cannot send a different decommitment, just because there is none. Maybe I'm wrong and I just don't understand your attack. In this case, please explain it more detail. Regards, Tim From natanael.l at gmail.com Thu Feb 15 22:44:05 2018 From: natanael.l at gmail.com (Natanael) Date: Thu, 15 Feb 2018 23:44:05 +0100 Subject: [bitcoin-dev] Transition to post-quantum In-Reply-To: <1518731861.3550.131.camel@mmci.uni-saarland.de> References: <1518450650.7829.87.camel@mmci.uni-saarland.de> <1518504374.9878.24.camel@mmci.uni-saarland.de> <882306fa-3ea0-99bd-61c6-f646d27c2ab6@gmail.com> <1518710367.3550.111.camel@mmci.uni-saarland.de> <1518731861.3550.131.camel@mmci.uni-saarland.de> Message-ID: Den 15 feb. 2018 22:58 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev at lists.linuxfoundation.org>: Also, the miners will indeed see one valid decommitment. This decommitment may have been sent by the attacker but it's the preimage chal of the address, because otherwise it's not valid for the malicious commitment. But if the decommitment is chal, then this decommitment is also valid for the commitment of the honest user, which is earliest additionally. So the honest commitment wins. The attacker does not succeed and everything is fine. The reason why this works: There is only one unique decommitment for the UTXO (assuming H_addr is collision-resistant). The decommitment does not depend on the commitment. The attacker cannot send a different decommitment, just because there is none. If your argument is that we publish the full transaction minus the public key and signatures, just committing to it, and then revealing that later (which means an attacker can't modify the transaction in advance in a way that produces a valid transaction); Allowing expiration retains insecurity, while allowing expiration makes it a trivial DoS target. Anybody can flood the miners with invalid transaction commitments. No miner can ever prune invalid commitments until a valid transaction is finalized which conflicts with the invalid commitments. You can't even rate limit it safely. Like I said in the other thread, this is unreasonable. It's much more practical with simple hash commitment that you can "fold away" in a Merkle tree hash and which you don't need to validate until the full transaction is published. -------------- next part -------------- An HTML attachment was scrubbed... URL: From natanael.l at gmail.com Thu Feb 15 22:45:09 2018 From: natanael.l at gmail.com (Natanael) Date: Thu, 15 Feb 2018 23:45:09 +0100 Subject: [bitcoin-dev] Transition to post-quantum In-Reply-To: References: <1518450650.7829.87.camel@mmci.uni-saarland.de> <1518504374.9878.24.camel@mmci.uni-saarland.de> <882306fa-3ea0-99bd-61c6-f646d27c2ab6@gmail.com> <1518710367.3550.111.camel@mmci.uni-saarland.de> <1518731861.3550.131.camel@mmci.uni-saarland.de> Message-ID: Small correction, see edited quote Den 15 feb. 2018 23:44 skrev "Natanael" : Allowing expiration retains insecurity, while *NOT* allowing expiration makes it a trivial DoS target. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.ruffing at mmci.uni-saarland.de Thu Feb 15 23:44:19 2018 From: tim.ruffing at mmci.uni-saarland.de (Tim Ruffing) Date: Fri, 16 Feb 2018 00:44:19 +0100 Subject: [bitcoin-dev] Transition to post-quantum In-Reply-To: References: <1518450650.7829.87.camel@mmci.uni-saarland.de> <1518504374.9878.24.camel@mmci.uni-saarland.de> <882306fa-3ea0-99bd-61c6-f646d27c2ab6@gmail.com> <1518710367.3550.111.camel@mmci.uni-saarland.de> <1518731861.3550.131.camel@mmci.uni-saarland.de> Message-ID: <1518738259.3550.170.camel@mmci.uni-saarland.de> On Thu, 2018-02-15 at 23:44 +0100, Natanael wrote: > If your argument is that we publish the full transaction minus the > public key and signatures, just committing to it, and then revealing > that later (which means an attacker can't modify the transaction in > advance in a way that produces a valid transaction); Almost. Actually we reveal the entire transaction later. > > [...] while *NOT* allowing expiration makes it a trivial DoS target. > > Anybody can flood the miners with invalid transaction commitments. No > miner can ever prune invalid commitments until a valid transaction is > finalized which conflicts with the invalid commitments. You can't > even rate limit it safely. Yes, that's certainly true. I mentioned that issue already. You can rate limit this: The only thing I see is that one can require transaction fees even for commitments. That's super annoying, because you need a second (PQ-)UTXO just to commit. But it's not impossible. You can call this impractical and this may well be true. But what will be most practical in the future depends on many parameters that are totally unclear at the moment, e.g., the efficiency of zero-knowledge proof systems. Who knows? If you would like to use zero-knowledge proofs to recover an UTXO with an P2PKH address, you need to prove in zero-knowledge that you know some secret key x such that H(g^x)=addr. That seems plausible. But P2PKH is by far the simplest example. For arbitrary scripts, this can become pretty complex and nasty, even if our proof systems and machines are fast enough. From jl2012 at xbt.hk Fri Feb 16 22:49:17 2018 From: jl2012 at xbt.hk (Johnson Lau) Date: Fri, 16 Feb 2018 17:49:17 -0500 Subject: [bitcoin-dev] Alternative way to count sigops Message-ID: <0213B102-7595-4177-A76C-FE4E8D7F0EDF@xbt.hk> Short history ---------------- Satoshi introduced sigops counting as a softfork to limit the number of signature operation in a block. He statically counted all OP_CHECK(MULTI)SIG(VERIFY) in both scriptSig and scriptPubKey, assumed a OP_CHECKMULTISIG is equivalent to 20 OP_CHECKSIG, and enforced a block limit of 20000 sigop. The counting is not contextual, i.e. one doesn?t need the UTXO set to determine the number of sigop. The counting was also static so one doesn?t need to execute a script in order to count sigop. However, this is completely wrong for few reasons: a) opcodes in scriptPubKey are not executed; b) scriptPubKey of spent UTXO, which are actually executed, are not counted at all; c) it greatly overestimate the cost of multi-sig; d) it counts sigop in unexecuted branch. As P2SH was introduced, sigop counting also covered the sigop redeemScript. This is good because redeemScript is what being executed. It also improved the counting of OP_CHECKMULTISIG. If it is in certain canonical form, it would count the number of public keys instead of assuming it as 20. On the other hand, counting sigop becomes not possible without the UTXO set, since one needs UTXO to identify P2SH inputs. Also, the canonical OP_CHECKMULTISIG counting is not quite elegant and created more special cases in the code. Segwit (BIP141) scaled the legacy sigop limit by 4x. So every legacy sigop becomes 4 new sigop, with a block limit of 80000 new sigop. P2WPKH is counted as 1 new sigop, and P2WSH is counted in the same way as P2SH. Problem ------------ We now have multiple 2nd generation script proposals, such as BIP114, BIP117, taproot, etc. BIP114 and taproot allows static sigop counting, but not BIP117 as it requires execution to determine what would be run as script (like OP_EVAL). As we want to allow more complicated script functions, static sigop counting might not be easy. However, we still want to have a limit to avoid unexpected DoS attack. Proposal ------------ Since we have a block weight limit of 4,000,000 and sigop limit of 80,000, each sigop could not use more than 50 weight unit on average. For new script proposals we could count the actual number of sigop at execution (i.e. skip unexecuted sigop, skip 0-size signature, count the actual checksig operations in multi-sig), and make sure the number of executed sigop * 50 is not greater than the size of the input. The minimal size of each input is 32 (prevout.hash) + 4 (prevout.n) + 4 (nSequence) + 1 (empty scriptSig) = 41 bytes or 164 weight unit. So the new rule would require that (164 + input witness size) >= (actual_sigop * 50). This is a per-input limit, as script validation is parallel. Since a compressed key is 33 bytes and a normal compact signature is 64 bytes, the 1:50 ratio should be more than enough to allow any normal use of CHECKSIG, unless people are doing weird things like 2DUP 2DUP 2DUP??..CHECKSIG CHECKSIG CHECKSIG CHECKSIG , which would have many sigop with a relatively small witness. Interactive per-tx signature aggregation allows 64bytes/tx signature, and per-block non-interatcitve signature aggregation allows 32bytes/signature (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014272.html ). In such cases, the 1:50 ratio might not be enough if many signatures are aggregated. Depends on the number of sigop we could tolerate, the 1:50 ratio might be reduced to 1:32 or lower to make sure legitimate use would never hit the limit. I think 32 is reasonable as it is about the size of a public key, which would guarantee each pubkey must get a sigop slot. So a relay node could be certain that a tx won?t spend excessive CPU power by just looking at its size. If it spends too much, it is invalid and script execution could be terminated early. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: Message signed with OpenPGP URL: From greg at xiph.org Sat Feb 17 02:33:32 2018 From: greg at xiph.org (Gregory Maxwell) Date: Sat, 17 Feb 2018 02:33:32 +0000 Subject: [bitcoin-dev] Alternative way to count sigops In-Reply-To: <0213B102-7595-4177-A76C-FE4E8D7F0EDF@xbt.hk> References: <0213B102-7595-4177-A76C-FE4E8D7F0EDF@xbt.hk> Message-ID: On Fri, Feb 16, 2018 at 10:49 PM, Johnson Lau via bitcoin-dev wrote: > Since we have a block weight limit of 4,000,000 and sigop limit of 80,000, > each sigop could not use more than 50 weight unit on average. For new script > proposals we could count the actual number of sigop at execution (i.e. skip > unexecuted sigop, skip 0-size signature, count the actual checksig > operations in multi-sig), and make sure the number of executed sigop * 50 is > not greater than the size of the input. We have a related policy rule in Bitcoin Core for some time now, the weight of the transaction for the purpose of mining is max(weight,lambda*sigops), though we set lambda a bit lower than makes sense due to how checkmultisig. This policy rule replaced an earlier one which was almost equivalent to your proposal: it rejected transactions with too many sigops per the byte count, but we found it block actual more or less sensible transactions. Going forward I don't think this is a great framework. It works if the only expensive operations all involve large input data, but I think many proposals people have made for new operations would have computational cost which requires relatively small amounts of additional input-- aggregation is just one fairly minor example. From cannon at cannon-ciota.info Sun Feb 18 16:20:13 2018 From: cannon at cannon-ciota.info (CANNON) Date: Sun, 18 Feb 2018 16:20:13 +0000 Subject: [bitcoin-dev] NIST 8202 Blockchain Technology Overview In-Reply-To: References: Message-ID: <39d9da2d-c462-66bc-1b24-f5531265018b@cannon-ciota.info> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Pardon my unproffesional tone in my original comment. But thank you for passing on these corrections. This looks much better. I have a few comments that might lend to making this even more accurate or complete. It is nice to see Bitcoin Cash use the proper ticket "BCH" and with clarrification that segregated witness was a softfork (backwards compatible and optional to unupgraded nodes) instead of a hardfork. While segwit might seem to compact more transactions to unupgraded nodes still using the 1 MB blocksize limit (because signature data is stored outside of this legacy 1MB limit), segwit is not actually more compact, but rather is a conservative blocksize increase as a result of the new block space made available through segwit upgrade. (One question I do have, which I am going to ask on the bitcoin-dev mailing list, is "Is the increased blockspace made available through SegWit limited to just witness data?") Segwit is not just about increased blockspace or transaction capactity though, but also has more advantages as a result of seperating the signature into a different segment. More information can be found here https://bitcoincore.org/en/2016/01/26/segwit-benefits/ One advantage is with segwit seperating the signature data, advanced smart contracts and functions on top of bitcoin can be used. This is due to transaction IDs being able to be calculated without signatures, or before being signed. Segwit also increases signature security, and if I am correct enables signatures algorithms to be able to be upgraded via a softfork. Segwit also enables Lightning Network. Lightning Network upgrade to Bitcoin enables instant and really cheap transactions which can handle micropayments and massive scaling of throughput of transactions per second. With micropayment networks such as Lightning Network, payments can be made off-chain, while still being enforced by and settled on the Bitcoin blockchain. The Bitcoin blockchain would act as a settlement or dispute layer. As a result this would also result in freed up space on the bitcoin blockchain as well. The political reasons which differ from the "bitcoin cash" crowd, and the "bitcoin" crowd is the long term vision of how to scale Bitcoin. The majority of the "bitcoin cash" crowd believes that scaling should be done by simply raising the blocksize. The majority of the "bitcoin" crowd, believes that increasing the blocksize to accomodate for all transactions like what "bitcoin cash" is doing, would lead to dangerous centralization of whom would able to operate a Bitcoin node. This is due to the factors of both storage, and bandwidth which are needed to sync and store the blockchain by nodes. https://lightning.network/lightning-network-paper.pdf Paper: The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments DRAFT Version 0.5.9.2 page 2-3 outlines a good description of why increasing the blocksize to accomodate every global transaction as a scaling solution is not feasible. In summary, So while the majority of the bitcoin crowd see micropayment channels and micropayment networks on higher layers as the next step in scaling for handling majority of transactions, the "bitcoin cash" supporters prefer to simply increase the blocksize to handle all these transactions. I plan on reading the rest of this paper to see if I have any other things to add. Cannon PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 Email: cannon at cannon-ciota.info NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE. On 01/29/2018 12:25 PM, XXXXXName removed for privacyXXXXXX wrote: > Thank you for your comments. You, along with many others, expressed > concern on section 8.1.2. To help foster a full transparency approach > on the editing of this section, I am sending the revised section to > you for further comment. > > 8.1.2 Bitcoin Cash (BCH) > In 2017, Bitcoin users adopted an improvement proposal for Segregated Witness > (known as SegWit, where transactions are split into two segments: > transactional data, and signature data) through a soft fork. SegWit > made it possible to store transactional data in a more compact > form while maintaining backwards compatibility. However, a group > of users had different opinions on how Bitcoin should evolve and > developed a hard fork of the Bitcoin blockchain titled Bitcoin > Cash. Rather than implementing the SegWit changes, the developers > of Bitcoin Cash decided to simply increase the blocksize. When the > hard fork occurred, people had access to the same amount of coins > on Bitcoin and Bitcoin Cash. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJaiabpAAoJEAYDai9lH2mwOVMP/id1xlK7Z7Sx0YpRD0SOHPw2 Ly/C42TQKH/w5zW5NnzndFJhgrLw68FDHcNRXF7NkryJBH9uZC0PuK/F7p2fGfdc OAGAnz6dGJKi3aIXS9wyuLXCOBRuBN/PEOTiYk8t7HZ8n60Lsdo5zMxZhuS7QNdu g1w3UtosNNXU5+9l4LpcRfynXSCCnh1EnNHa9qTIjmCJIjphnpu/hGVAIYWrYwof AgcEMnv+KseYl6zWs7l5+nevAiDjxrUGEuHDUD9N0+kSLYv3Jsp8t++6q5gdtAI4 xfbyZaIOrSidSe3iSNCnHYuf6TQ/+RstvgPd4VfPJsCK+jVxuJ5R3MC0b5+3cWGU iUnYsPuX7lKE00B/tW8gVoyVtzYc4eiv8Tp50GeI4Gv6n4K+QuKM82S9DPfn1Ku8 1vJpyL4LrZLkhmYGdTt2ajmg88wXpcySfaPa+xEY0bFziqEqnKgQgwAv1p3a5PbM WCU2x8Hrv8mMR/RCpo4I0QmkdZfM6ITHGRX/WZa3MVdHB8C1hqT574AKyWvzse4K YxIdbDZU0cjE5o7oOqTRAF1uR7XD2v8XAbyqQJaHi9z9n8l+CbyEXwNIHAWTkPPb OVGmnECTCxE0ZZAyaYWaAEnK3FnYEWlF92LKUmjQxD6+1YkCiEe0X2AwFibXw3at FPcZUkjeX+c7YDArq20l =Ryov -----END PGP SIGNATURE----- From cannon at cannon-ciota.info Sun Feb 18 16:26:14 2018 From: cannon at cannon-ciota.info (CANNON) Date: Sun, 18 Feb 2018 16:26:14 +0000 Subject: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data? Message-ID: <640e2daf-343d-62be-d6da-a2c1b4bc2bfd@cannon-ciota.info> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have a question in reference to the increased blockspace enabled by the segregated witness upgrade. Is this extra blockspace beyond the legacy 1 MB limit limited to just witness data? - -- Cannon PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 Email: cannon at cannon-ciota.info NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJaiajLAAoJEAYDai9lH2mwDbMQAKgJseZG9oOoP9WJlESFdAzm jLM69KLF4RVWDQjMWCtyVayyolXMLavW6fL4GL7/ztLYSl9Pz+FDlH3Qgo1GLDx4 fRUkmb0ApLBSAjmdqM+kWjgq3s6/oZaIkNxGeyK5SYY4QhF80Z42PWLBPKjAc7vn pe7Im13NwtyJiRuCmq4e1z6GmW86fFOKOsR4rlWcftHOFmH8Gz5d9KK9LbPqU6Ca +rde8yb+A9uXEv3O9MqeLId7FYSJixgzFGJosidVkAVQI7YZ0TAfG4HSwKjtqDz7 SW2Bs3nDeiCr2QN7Su9TUaoSN/yKTBOw5jnql9cNOYuf4GAG0MXWinmYP8MWCiqh bIrzvOnlZGapX/36Fpab67VDcFnXJJc8ofqYmn+oUoW/q7geQpu/V1oz+AR9nD/d n8wFxvZdRlTbq2XDXySaontxNH0rd80fSG5SJtO5Js9hK/vNG+Xa7Zc+76gEtvlF 5G1F6MOcsoXUDCnMteuNxaZx6TPML6RuWVmbR1wXOaX4qZ01p7AsjQlTIcrlVDsB LVGW70wjfETBCffn1JQvFmIK7NzggIUuYfLF0IrfM4BrTa/01RnmfBOpWGiIvyIG qZqKLYDbW7BDkc/HMtAonR/0t6bTUv/388USSnbMakO9bvih0xxIw4NWTyoSoef/ I+W6ny7qXt+pegLF4cYL =YqEM -----END PGP SIGNATURE----- From rhavar at protonmail.com Sun Feb 18 17:04:17 2018 From: rhavar at protonmail.com (rhavar at protonmail.com) Date: Sun, 18 Feb 2018 12:04:17 -0500 Subject: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data? In-Reply-To: <640e2daf-343d-62be-d6da-a2c1b4bc2bfd@cannon-ciota.info> References: <640e2daf-343d-62be-d6da-a2c1b4bc2bfd@cannon-ciota.info> Message-ID: <9IZu22-jNUMzMcq7VK0qdzd2tj333lWOhOUe3A5V6OUaFlpQiS8lRFm-ZdGew4Im5KQ9qF4nF3WT3QugHMVrOi3Lr82FvyH9w-XG32NH7oQ=@protonmail.com> No, you are misunderstanding. The block size limit (1MB) has been replaced in favor of a block weight limit (4M weight). Bytes which must be sent to old clients are weighted at 4 units each which is what allows it to be a soft fork. So as such, there's not two separate limits or anything. P.S. what's up with your signature lol ?-Ryan ? -------- Original Message -------- On February 18, 2018 11:26 AM, CANNON via bitcoin-dev wrote: >-----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > I have a question in reference to the increased blockspace enabled > by the segregated witness upgrade. Is this extra blockspace beyond > the legacy 1 MB limit limited to just witness data? > > > >Cannon > PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 > Email: cannon at cannon-ciota.info > > NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE. > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJaiajLAAoJEAYDai9lH2mwDbMQAKgJseZG9oOoP9WJlESFdAzm > jLM69KLF4RVWDQjMWCtyVayyolXMLavW6fL4GL7/ztLYSl9Pz+FDlH3Qgo1GLDx4 > fRUkmb0ApLBSAjmdqM+kWjgq3s6/oZaIkNxGeyK5SYY4QhF80Z42PWLBPKjAc7vn > pe7Im13NwtyJiRuCmq4e1z6GmW86fFOKOsR4rlWcftHOFmH8Gz5d9KK9LbPqU6Ca > +rde8yb+A9uXEv3O9MqeLId7FYSJixgzFGJosidVkAVQI7YZ0TAfG4HSwKjtqDz7 > SW2Bs3nDeiCr2QN7Su9TUaoSN/yKTBOw5jnql9cNOYuf4GAG0MXWinmYP8MWCiqh > bIrzvOnlZGapX/36Fpab67VDcFnXJJc8ofqYmn+oUoW/q7geQpu/V1oz+AR9nD/d > n8wFxvZdRlTbq2XDXySaontxNH0rd80fSG5SJtO5Js9hK/vNG+Xa7Zc+76gEtvlF > 5G1F6MOcsoXUDCnMteuNxaZx6TPML6RuWVmbR1wXOaX4qZ01p7AsjQlTIcrlVDsB > LVGW70wjfETBCffn1JQvFmIK7NzggIUuYfLF0IrfM4BrTa/01RnmfBOpWGiIvyIG > qZqKLYDbW7BDkc/HMtAonR/0t6bTUv/388USSnbMakO9bvih0xxIw4NWTyoSoef/ > I+W6ny7qXt+pegLF4cYL > =YqEM > -----END PGP SIGNATURE----- > >bitcoin-dev mailing list >bitcoin-dev at lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > From austin at apextox.com Sun Feb 18 16:57:49 2018 From: austin at apextox.com (Austin Maier) Date: Sun, 18 Feb 2018 11:57:49 -0500 Subject: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data? In-Reply-To: <640e2daf-343d-62be-d6da-a2c1b4bc2bfd@cannon-ciota.info> References: <640e2daf-343d-62be-d6da-a2c1b4bc2bfd@cannon-ciota.info> Message-ID: Effectively yes. The discount on weight applies to the witness data. On Feb 18, 2018 11:42 AM, "CANNON via bitcoin-dev" < bitcoin-dev at lists.linuxfoundation.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > I have a question in reference to the increased blockspace enabled > by the segregated witness upgrade. Is this extra blockspace beyond > the legacy 1 MB limit limited to just witness data? > > > - -- > Cannon > PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 > Email: cannon at cannon-ciota.info > > NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE. > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJaiajLAAoJEAYDai9lH2mwDbMQAKgJseZG9oOoP9WJlESFdAzm > jLM69KLF4RVWDQjMWCtyVayyolXMLavW6fL4GL7/ztLYSl9Pz+FDlH3Qgo1GLDx4 > fRUkmb0ApLBSAjmdqM+kWjgq3s6/oZaIkNxGeyK5SYY4QhF80Z42PWLBPKjAc7vn > pe7Im13NwtyJiRuCmq4e1z6GmW86fFOKOsR4rlWcftHOFmH8Gz5d9KK9LbPqU6Ca > +rde8yb+A9uXEv3O9MqeLId7FYSJixgzFGJosidVkAVQI7YZ0TAfG4HSwKjtqDz7 > SW2Bs3nDeiCr2QN7Su9TUaoSN/yKTBOw5jnql9cNOYuf4GAG0MXWinmYP8MWCiqh > bIrzvOnlZGapX/36Fpab67VDcFnXJJc8ofqYmn+oUoW/q7geQpu/V1oz+AR9nD/d > n8wFxvZdRlTbq2XDXySaontxNH0rd80fSG5SJtO5Js9hK/vNG+Xa7Zc+76gEtvlF > 5G1F6MOcsoXUDCnMteuNxaZx6TPML6RuWVmbR1wXOaX4qZ01p7AsjQlTIcrlVDsB > LVGW70wjfETBCffn1JQvFmIK7NzggIUuYfLF0IrfM4BrTa/01RnmfBOpWGiIvyIG > qZqKLYDbW7BDkc/HMtAonR/0t6bTUv/388USSnbMakO9bvih0xxIw4NWTyoSoef/ > I+W6ny7qXt+pegLF4cYL > =YqEM > -----END PGP SIGNATURE----- > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From falke.marco at gmail.com Sun Feb 18 18:57:03 2018 From: falke.marco at gmail.com (Marco Falke) Date: Sun, 18 Feb 2018 13:57:03 -0500 Subject: [bitcoin-dev] Amend the BIP 123 process to include buried deployments In-Reply-To: <8fb2e424-268c-7433-5f6b-5fbab5c5cc5c@voskuil.org> References: <8fb2e424-268c-7433-5f6b-5fbab5c5cc5c@voskuil.org> Message-ID: > They also do not require software coordination. Therefore, why should there be > BIPs at all? Seems to me that we should instead add these documents to > https://github.com/bitcoin-core/docs Consensus is not trivial. I think documentation is important, even if it seems simple to some. Personally, I don't care too much where to place the documentation, but the BIPs repo seems a good place, since it also hosts other informational documents. To prevent "two BIPs for every protocol change", related buried deployments could be bundled. E.g. the ISM BIP 90 change. On Wed, Feb 14, 2018 at 6:57 PM, Eric Voskuil wrote: > On 02/14/2018 02:01 PM, Marco Falke via bitcoin-dev wrote: >> I define a buried deployment as a consensus rule change that affects >> validity of blocks that are buried by a sufficiently large number of >> blocks in the current valid most-work chain, > > Sufficient for what, specifically? Sufficiently large to prevent potential bike-shedding. The expected number of blocks in two weeks could be considered a lower bound. Then multiply that by 10 or 20. > >> but the current block (and all its parents) remain valid. > > Remain valid in the case where the depth assumption is "sufficient" to > ensure that a chain split is not possible? > > If this was true (which it is not), it would imply that there is no > reason to validate any block deeper than the most recent 25,000. > Presumably this means that people may continuously rely on some > authority (like Bitcoin Core?) to determine the checkpoint for tip-25,000. > Note that a checkpoint *freezes* the chain completely at a given height. Buried deployments are *not* checkpoints. Also note that buried deployments only make sense after a protocol upgrade has happened (i.e. a soft fork or hard fork). If a miner has the resources to cause a chain split, they could trivially do that even in the complete absence of buried deployments. Buried deployments are *not* a solution to 50% attacks. >> BIP 123 suggests that BIPs in the consensus layer should be assigned a >> label "soft fork" or "hard fork". However, I think the differentiation >> into soft fork or hard fork should not be made for BIPs that document >> buried deployments. In contrast to soft forks and hard forks, buried >> deployments do not require community and miner coordination for a safe >> deployment. > > They can only avoid this requirement based on the assumption that the > hard fork cannot result in a chain split. This is not the case. > >> For a chain fork to happen due to a buried deployment, a massive chain >> reorganization must be produced off of a block in the very past. > > In other words a "buried deployment" is a hard fork that is not likely > to cause a chain split. This is a subjective subcategory of hard fork, > not an independent category - unless maybe you can show that there is > the 25,000 blocks number is an objective threshold. Please note that a buried deployment can very well be a soft fork. I think this makes it even clearer, that such a label makes no sense for buried deployments. >> In the extremely unlikely event of such a large chain reorganization, >> Bitcoin's general security assumptions would be violated regardless of >> the presence of a buried deployment. > > This is untrue. The "security assumptions" of Bitcoin do not preclude > deep reorganizations. > e > From eric at voskuil.org Sun Feb 18 18:39:09 2018 From: eric at voskuil.org (Eric Voskuil) Date: Sun, 18 Feb 2018 10:39:09 -0800 Subject: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data? In-Reply-To: <9IZu22-jNUMzMcq7VK0qdzd2tj333lWOhOUe3A5V6OUaFlpQiS8lRFm-ZdGew4Im5KQ9qF4nF3WT3QugHMVrOi3Lr82FvyH9w-XG32NH7oQ=@protonmail.com> References: <640e2daf-343d-62be-d6da-a2c1b4bc2bfd@cannon-ciota.info> <9IZu22-jNUMzMcq7VK0qdzd2tj333lWOhOUe3A5V6OUaFlpQiS8lRFm-ZdGew4Im5KQ9qF4nF3WT3QugHMVrOi3Lr82FvyH9w-XG32NH7oQ=@protonmail.com> Message-ID: <5E8E7227-8F90-40A2-B3D6-CA9D03CD3FEC@voskuil.org> As a soft fork, all preceding rules remain in effect. No rule has been ?replaced?. Blocks must validate against pre-segwit rules or are invalid. Additional rules are applied that further restrict validity, and consider additional (witness) data in the context of the block. e > On Feb 18, 2018, at 09:04, Ryan Havar via bitcoin-dev wrote: > > No, you are misunderstanding. The block size limit (1MB) has been replaced in favor of a block weight limit (4M weight). Bytes which must be sent to old clients are weighted at 4 units each which is what allows it to be a soft fork. > > So as such, there's not two separate limits or anything. > > P.S. what's up with your signature lol > > > ?-Ryan > > ? > > -------- Original Message -------- >> On February 18, 2018 11:26 AM, CANNON via bitcoin-dev wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> I have a question in reference to the increased blockspace enabled >> by the segregated witness upgrade. Is this extra blockspace beyond >> the legacy 1 MB limit limited to just witness data? >> >> >> >> Cannon >> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 >> Email: cannon at cannon-ciota.info >> >> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD >> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE. >> -----BEGIN PGP SIGNATURE----- >> >> iQIcBAEBCgAGBQJaiajLAAoJEAYDai9lH2mwDbMQAKgJseZG9oOoP9WJlESFdAzm >> jLM69KLF4RVWDQjMWCtyVayyolXMLavW6fL4GL7/ztLYSl9Pz+FDlH3Qgo1GLDx4 >> fRUkmb0ApLBSAjmdqM+kWjgq3s6/oZaIkNxGeyK5SYY4QhF80Z42PWLBPKjAc7vn >> pe7Im13NwtyJiRuCmq4e1z6GmW86fFOKOsR4rlWcftHOFmH8Gz5d9KK9LbPqU6Ca >> +rde8yb+A9uXEv3O9MqeLId7FYSJixgzFGJosidVkAVQI7YZ0TAfG4HSwKjtqDz7 >> SW2Bs3nDeiCr2QN7Su9TUaoSN/yKTBOw5jnql9cNOYuf4GAG0MXWinmYP8MWCiqh >> bIrzvOnlZGapX/36Fpab67VDcFnXJJc8ofqYmn+oUoW/q7geQpu/V1oz+AR9nD/d >> n8wFxvZdRlTbq2XDXySaontxNH0rd80fSG5SJtO5Js9hK/vNG+Xa7Zc+76gEtvlF >> 5G1F6MOcsoXUDCnMteuNxaZx6TPML6RuWVmbR1wXOaX4qZ01p7AsjQlTIcrlVDsB >> LVGW70wjfETBCffn1JQvFmIK7NzggIUuYfLF0IrfM4BrTa/01RnmfBOpWGiIvyIG >> qZqKLYDbW7BDkc/HMtAonR/0t6bTUv/388USSnbMakO9bvih0xxIw4NWTyoSoef/ >> I+W6ny7qXt+pegLF4cYL >> =YqEM >> -----END PGP SIGNATURE----- >> >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev From rhavar at protonmail.com Sun Feb 18 19:04:57 2018 From: rhavar at protonmail.com (rhavar at protonmail.com) Date: Sun, 18 Feb 2018 14:04:57 -0500 Subject: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data? In-Reply-To: <5E8E7227-8F90-40A2-B3D6-CA9D03CD3FEC@voskuil.org> References: <640e2daf-343d-62be-d6da-a2c1b4bc2bfd@cannon-ciota.info> <9IZu22-jNUMzMcq7VK0qdzd2tj333lWOhOUe3A5V6OUaFlpQiS8lRFm-ZdGew4Im5KQ9qF4nF3WT3QugHMVrOi3Lr82FvyH9w-XG32NH7oQ=@protonmail.com> <5E8E7227-8F90-40A2-B3D6-CA9D03CD3FEC@voskuil.org> Message-ID: > No rule has been ?replaced?. It really has been. The code is no longer checks the size of a block, but the weight of it. For all intents and purposes the block size limits has been replaced in favor of a block weight limit. It's just been designed such that the new rule is more restrictive than the one it replaces. Now, I'm not doubting you can argue the semantics on the difference between "replacing with a more restrictive rule" and "leaving the existing rules, but adding a new one" -- but it's uninteresting and only serves to confuse novice's like CANNON into thinking that there are two rules/spaces/limits for transactions. ?-Ryan ? -------- Original Message -------- On February 18, 2018 1:39 PM, Eric Voskuil wrote: >As a soft fork, all preceding rules remain in effect. No rule has been ?replaced?. Blocks must validate against pre-segwit rules or are invalid. Additional rules are applied that further restrict validity, and consider additional (witness) data in the context of the block. > > e > >>On Feb 18, 2018, at 09:04, Ryan Havar via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote: >>No, you are misunderstanding. The block size limit (1MB) has been replaced in favor of a block weight limit (4M weight). Bytes which must be sent to old clients are weighted at 4 units each which is what allows it to be a soft fork. >>So as such, there's not two separate limits or anything. >>P.S. what's up with your signature lol >>?-Ryan >>? >>-------- Original Message -------- >>>On February 18, 2018 11:26 AM, CANNON via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote: >>>-----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>>I have a question in reference to the increased blockspace enabled >>> by the segregated witness upgrade. Is this extra blockspace beyond >>> the legacy 1 MB limit limited to just witness data? >>>Cannon >>> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 >>> Email: cannon at cannon-ciota.info >>>NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD >>> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE. >>> -----BEGIN PGP SIGNATURE----- >>>iQIcBAEBCgAGBQJaiajLAAoJEAYDai9lH2mwDbMQAKgJseZG9oOoP9WJlESFdAzm >>> jLM69KLF4RVWDQjMWCtyVayyolXMLavW6fL4GL7/ztLYSl9Pz+FDlH3Qgo1GLDx4 >>> fRUkmb0ApLBSAjmdqM+kWjgq3s6/oZaIkNxGeyK5SYY4QhF80Z42PWLBPKjAc7vn >>> pe7Im13NwtyJiRuCmq4e1z6GmW86fFOKOsR4rlWcftHOFmH8Gz5d9KK9LbPqU6Ca >>> +rde8yb+A9uXEv3O9MqeLId7FYSJixgzFGJosidVkAVQI7YZ0TAfG4HSwKjtqDz7 >>> SW2Bs3nDeiCr2QN7Su9TUaoSN/yKTBOw5jnql9cNOYuf4GAG0MXWinmYP8MWCiqh >>> bIrzvOnlZGapX/36Fpab67VDcFnXJJc8ofqYmn+oUoW/q7geQpu/V1oz+AR9nD/d >>> n8wFxvZdRlTbq2XDXySaontxNH0rd80fSG5SJtO5Js9hK/vNG+Xa7Zc+76gEtvlF >>> 5G1F6MOcsoXUDCnMteuNxaZx6TPML6RuWVmbR1wXOaX4qZ01p7AsjQlTIcrlVDsB >>> LVGW70wjfETBCffn1JQvFmIK7NzggIUuYfLF0IrfM4BrTa/01RnmfBOpWGiIvyIG >>> qZqKLYDbW7BDkc/HMtAonR/0t6bTUv/388USSnbMakO9bvih0xxIw4NWTyoSoef/ >>> I+W6ny7qXt+pegLF4cYL >>> =YqEM >>> -----END PGP SIGNATURE----- >>>bitcoin-dev mailing list >>>bitcoin-dev at lists.linuxfoundation.org >>>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>bitcoin-dev mailing list >>bitcoin-dev at lists.linuxfoundation.org >>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > From eric at voskuil.org Sun Feb 18 19:14:22 2018 From: eric at voskuil.org (Eric Voskuil) Date: Sun, 18 Feb 2018 11:14:22 -0800 Subject: [bitcoin-dev] Increased blockspace enabled by SegWit limited to just witness data? In-Reply-To: References: <640e2daf-343d-62be-d6da-a2c1b4bc2bfd@cannon-ciota.info> <9IZu22-jNUMzMcq7VK0qdzd2tj333lWOhOUe3A5V6OUaFlpQiS8lRFm-ZdGew4Im5KQ9qF4nF3WT3QugHMVrOi3Lr82FvyH9w-XG32NH7oQ=@protonmail.com> <5E8E7227-8F90-40A2-B3D6-CA9D03CD3FEC@voskuil.org> Message-ID: <54BE283E-5DD2-4BD4-9218-DD9E9AFC8A99@voskuil.org> If the new rule is more restrictive the original limit remains. e On Feb 18, 2018, at 11:04, rhavar at protonmail.com wrote: >> No rule has been ?replaced?. > > It really has been. The code is no longer checks the size of a block, but the weight of it. For all intents and purposes the block size limits has been replaced in favor of a block weight limit. It's just been designed such that the new rule is more restrictive than the one it replaces. > > Now, I'm not doubting you can argue the semantics on the difference between "replacing with a more restrictive rule" and "leaving the existing rules, but adding a new one" -- but it's uninteresting and only serves to confuse novice's like CANNON into thinking that there are two rules/spaces/limits for transactions. > > > > ?-Ryan > > ? > > -------- Original Message -------- >> On February 18, 2018 1:39 PM, Eric Voskuil wrote: >> >> As a soft fork, all preceding rules remain in effect. No rule has been ?replaced?. Blocks must validate against pre-segwit rules or are invalid. Additional rules are applied that further restrict validity, and consider additional (witness) data in the context of the block. >> >> e >> >>> On Feb 18, 2018, at 09:04, Ryan Havar via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote: >>> No, you are misunderstanding. The block size limit (1MB) has been replaced in favor of a block weight limit (4M weight). Bytes which must be sent to old clients are weighted at 4 units each which is what allows it to be a soft fork. >>> So as such, there's not two separate limits or anything. >>> P.S. what's up with your signature lol >>> ?-Ryan >>> ? >>> -------- Original Message -------- >>>> On February 18, 2018 11:26 AM, CANNON via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA512 >>>> I have a question in reference to the increased blockspace enabled >>>> by the segregated witness upgrade. Is this extra blockspace beyond >>>> the legacy 1 MB limit limited to just witness data? >>>> Cannon >>>> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 >>>> Email: cannon at cannon-ciota.info >>>> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD >>>> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE. >>>> -----BEGIN PGP SIGNATURE----- >>>> iQIcBAEBCgAGBQJaiajLAAoJEAYDai9lH2mwDbMQAKgJseZG9oOoP9WJlESFdAzm >>>> jLM69KLF4RVWDQjMWCtyVayyolXMLavW6fL4GL7/ztLYSl9Pz+FDlH3Qgo1GLDx4 >>>> fRUkmb0ApLBSAjmdqM+kWjgq3s6/oZaIkNxGeyK5SYY4QhF80Z42PWLBPKjAc7vn >>>> pe7Im13NwtyJiRuCmq4e1z6GmW86fFOKOsR4rlWcftHOFmH8Gz5d9KK9LbPqU6Ca >>>> +rde8yb+A9uXEv3O9MqeLId7FYSJixgzFGJosidVkAVQI7YZ0TAfG4HSwKjtqDz7 >>>> SW2Bs3nDeiCr2QN7Su9TUaoSN/yKTBOw5jnql9cNOYuf4GAG0MXWinmYP8MWCiqh >>>> bIrzvOnlZGapX/36Fpab67VDcFnXJJc8ofqYmn+oUoW/q7geQpu/V1oz+AR9nD/d >>>> n8wFxvZdRlTbq2XDXySaontxNH0rd80fSG5SJtO5Js9hK/vNG+Xa7Zc+76gEtvlF >>>> 5G1F6MOcsoXUDCnMteuNxaZx6TPML6RuWVmbR1wXOaX4qZ01p7AsjQlTIcrlVDsB >>>> LVGW70wjfETBCffn1JQvFmIK7NzggIUuYfLF0IrfM4BrTa/01RnmfBOpWGiIvyIG >>>> qZqKLYDbW7BDkc/HMtAonR/0t6bTUv/388USSnbMakO9bvih0xxIw4NWTyoSoef/ >>>> I+W6ny7qXt+pegLF4cYL >>>> =YqEM >>>> -----END PGP SIGNATURE----- >>>> bitcoin-dev mailing list >>>> bitcoin-dev at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>> bitcoin-dev mailing list >>> bitcoin-dev at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> > From contact at taoeffect.com Mon Feb 19 01:29:50 2018 From: contact at taoeffect.com (Tao Effect) Date: Sun, 18 Feb 2018 20:29:50 -0500 Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW Message-ID: <0899818B-4A48-4A88-8624-B0B6F9536734@taoeffect.com> Copied from: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13 # Blockchain Timestamps Unnecessary In Proof-of-Work? *Author: Greg Slepak ([@taoeffect at mastodon.social ](https://mastodon.social/@taoeffect ))* ---- The Bitcoin blockchain has a 10-minute target blocktime that is achieved by a difficulty adjustment algorithm. I assert, or rather, pose the hypothesis, that the use of timestamps in Bitcoin's blockchain may be unnecessary, and that Bitcoin can operate with the same security guarantees without it (except as noted in [Risks and Mitigations](#risks-and-mitigations)), and therefore does not need miners to maintain global clock synchronization. The alternative difficulty adjustment algorithm would work according to the following principles: - The incentive for miners is and always has been to maximize profit. - The block reward algorithm is now modified to issue coins into perpetuity (no maximum). Any given block can issue _up to_ `X` number of coins per block. - The number of coins issued per block is now tied directly to the difficulty of the block, and the concept of "epocs" or "block reward halving" is removed. - The chain selection rule remains "chain with most proof of work" - The difficulty can be modified by miners in an arbitrary direction (up or down), but is limited in magnitude by some maximum percentage (e.g. no more than 20% deviation from the previous block), we call this `Y%`. ### Observations - Miners are free to mine blocks of whatever difficulty they choose, up to a maximum deviation - The blockchain may at times produce blocks very quickly, and at other times produce blocks more slowly - Powerful miners are incentivized to raise the difficulty to remove competitors (as is true today) - Whether miners choose to produce blocks quickly or slowly is entirely up to them. If they produce blocks quickly, each block has a lower reward, but there are more of them. If they produce blocks slowly, each block has a higher reward, but there are fewer of them. So an equilibrium will be naturally reached to produce blocks at a rate that should minimize orphans. A timestamp may still be included in blocks, but it no longer needs to be used for anything, or represent anything significant other than metadata about when the miner claims to have produced the block. ### Risks and Mitigations Such a system may introduce risks that require further modification of the protocol to mitigate. The most straightforward risk comes from the potential increase in total transaction throughput that such a change would introduce (these are the same concerns that exist with respect to raising the blocksize). The removal of timestamps would allow a cartel of miners to produce high-difficulty blocks at a fast rate, potentially resulting in additional centralization pressures not only on miners but also on full nodes who then would have greater difficulty keeping up with the additional bandwidth and storage demands. Two equally straightforward mitigations exist to address this if we are given the liberty of modifying the protocol as we wish: 1. Introducing state checkpoints into the chain itself could make it possible for full nodes to skip verification of large sections of historical data when booting up. 2. A sharded protocol, where each shard uses a "sufficiently different" PoW algorithm, would create an exit for users should the primary blockchain become captured by a cartel providing poor quality-of-service. -- Please do not email me anything that you are not comfortable also sharing with the NSA. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From contact at taoeffect.com Mon Feb 19 05:15:59 2018 From: contact at taoeffect.com (Tao Effect) Date: Mon, 19 Feb 2018 00:15:59 -0500 Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW In-Reply-To: References: Message-ID: <28E7F3BA-3D0E-4FF2-9143-FD79A0A029F5@taoeffect.com> Real quick (I've received some off-list replies and do plan to respond to those), want to be clear: this thread is not meant to be interpreted as a proposal to modify Bitcoin (it is not a BIP), it is just, exactly as the subject says, some thoughts I had that I hadn't seen expressed elsewhere, that I felt like sharing, in case they are at all useful/interesting to anyone. Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. > On Feb 19, 2018, at 12:10 AM, Ryan J Martin > wrote: > > To be frank, this kind of thing would be better off attempted as a fork to a new coin. Changing the max number of coins, the block reward, the difficulty algo, mining policy and protocol is going to be a non-starter. Also, what are the proposed quantifiavle benefits from removing timestamps? How would this be done at the protocol level? Are these other changes related to removing timestamps/rationale for other supply changes? > > Regards, > Ryan J. Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From rjmarti2 at millersville.edu Mon Feb 19 05:10:31 2018 From: rjmarti2 at millersville.edu (Ryan J Martin) Date: Mon, 19 Feb 2018 05:10:31 +0000 Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW Message-ID: To be frank, this kind of thing would be better off attempted as a fork to a new coin. Changing the max number of coins, the block reward, the difficulty algo, mining policy and protocol is going to be a non-starter. Also, what are the proposed quantifiavle benefits from removing timestamps? How would this be done at the protocol level? Are these other changes related to removing timestamps/rationale for other supply changes? Regards, Ryan J. Martin On Feb 18, 2018 10:01 PM, Tao Effect via bitcoin-dev wrote: Copied from: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13 # Blockchain Timestamps Unnecessary In Proof-of-Work? *Author: Greg Slepak ([@taoeffect at mastodon.social](https://mastodon.social/@taoeffect))* ---- The Bitcoin blockchain has a 10-minute target blocktime that is achieved by a difficulty adjustment algorithm. I assert, or rather, pose the hypothesis, that the use of timestamps in Bitcoin's blockchain may be unnecessary, and that Bitcoin can operate with the same security guarantees without it (except as noted in [Risks and Mitigations](#risks-and-mitigations)), and therefore does not need miners to maintain global clock synchronization. The alternative difficulty adjustment algorithm would work according to the following principles: - The incentive for miners is and always has been to maximize profit. - The block reward algorithm is now modified to issue coins into perpetuity (no maximum). Any given block can issue _up to_ `X` number of coins per block. - The number of coins issued per block is now tied directly to the difficulty of the block, and the concept of "epocs" or "block reward halving" is removed. - The chain selection rule remains "chain with most proof of work" - The difficulty can be modified by miners in an arbitrary direction (up or down), but is limited in magnitude by some maximum percentage (e.g. no more than 20% deviation from the previous block), we call this `Y%`. ### Observations - Miners are free to mine blocks of whatever difficulty they choose, up to a maximum deviation - The blockchain may at times produce blocks very quickly, and at other times produce blocks more slowly - Powerful miners are incentivized to raise the difficulty to remove competitors (as is true today) - Whether miners choose to produce blocks quickly or slowly is entirely up to them. If they produce blocks quickly, each block has a lower reward, but there are more of them. If they produce blocks slowly, each block has a higher reward, but there are fewer of them. So an equilibrium will be naturally reached to produce blocks at a rate that should minimize orphans. A timestamp may still be included in blocks, but it no longer needs to be used for anything, or represent anything significant other than metadata about when the miner claims to have produced the block. ### Risks and Mitigations Such a system may introduce risks that require further modification of the protocol to mitigate. The most straightforward risk comes from the potential increase in total transaction throughput that such a change would introduce (these are the same concerns that exist with respect to raising the blocksize). The removal of timestamps would allow a cartel of miners to produce high-difficulty blocks at a fast rate, potentially resulting in additional centralization pressures not only on miners but also on full nodes who then would have greater difficulty keeping up with the additional bandwidth and storage demands. Two equally straightforward mitigations exist to address this if we are given the liberty of modifying the protocol as we wish: 1. Introducing state checkpoints into the chain itself could make it possible for full nodes to skip verification of large sections of historical data when booting up. 2. A sharded protocol, where each shard uses a "sufficiently different" PoW algorithm, would create an exit for users should the primary blockchain become captured by a cartel providing poor quality-of-service. -- Please do not email me anything that you are not comfortable also sharing with the NSA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From willtech at live.com.au Mon Feb 19 09:04:02 2018 From: willtech at live.com.au (Damian Williamson) Date: Mon, 19 Feb 2018 09:04:02 +0000 Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW In-Reply-To: <0899818B-4A48-4A88-8624-B0B6F9536734@taoeffect.com> References: <0899818B-4A48-4A88-8624-B0B6F9536734@taoeffect.com> Message-ID: >1. Introducing state checkpoints into the chain itself could make it possible for full nodes to skip verification of large sections of historical data when booting up. What you are suggesting, unless I am mistaken, is that new full nodes should have no way of knowing if an output is spent or even if it exists. Since large sections of the blockchain will potentially be skipped, the full node will not have complete knowledge of utxo's just for starters. Regards, Damian Williamson ________________________________ From: bitcoin-dev-bounces at lists.linuxfoundation.org on behalf of Tao Effect via bitcoin-dev Sent: Monday, 19 February 2018 12:29:50 PM To: Bitcoin Protocol Discussion Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW Copied from: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/pull/13 # Blockchain Timestamps Unnecessary In Proof-of-Work? *Author: Greg Slepak ([@taoeffect at mastodon.social](https://mastodon.social/@taoeffect))* ---- The Bitcoin blockchain has a 10-minute target blocktime that is achieved by a difficulty adjustment algorithm. I assert, or rather, pose the hypothesis, that the use of timestamps in Bitcoin's blockchain may be unnecessary, and that Bitcoin can operate with the same security guarantees without it (except as noted in [Risks and Mitigations](#risks-and-mitigations)), and therefore does not need miners to maintain global clock synchronization. The alternative difficulty adjustment algorithm would work according to the following principles: - The incentive for miners is and always has been to maximize profit. - The block reward algorithm is now modified to issue coins into perpetuity (no maximum). Any given block can issue _up to_ `X` number of coins per block. - The number of coins issued per block is now tied directly to the difficulty of the block, and the concept of "epocs" or "block reward halving" is removed. - The chain selection rule remains "chain with most proof of work" - The difficulty can be modified by miners in an arbitrary direction (up or down), but is limited in magnitude by some maximum percentage (e.g. no more than 20% deviation from the previous block), we call this `Y%`. ### Observations - Miners are free to mine blocks of whatever difficulty they choose, up to a maximum deviation - The blockchain may at times produce blocks very quickly, and at other times produce blocks more slowly - Powerful miners are incentivized to raise the difficulty to remove competitors (as is true today) - Whether miners choose to produce blocks quickly or slowly is entirely up to them. If they produce blocks quickly, each block has a lower reward, but there are more of them. If they produce blocks slowly, each block has a higher reward, but there are fewer of them. So an equilibrium will be naturally reached to produce blocks at a rate that should minimize orphans. A timestamp may still be included in blocks, but it no longer needs to be used for anything, or represent anything significant other than metadata about when the miner claims to have produced the block. ### Risks and Mitigations Such a system may introduce risks that require further modification of the protocol to mitigate. The most straightforward risk comes from the potential increase in total transaction throughput that such a change would introduce (these are the same concerns that exist with respect to raising the blocksize). The removal of timestamps would allow a cartel of miners to produce high-difficulty blocks at a fast rate, potentially resulting in additional centralization pressures not only on miners but also on full nodes who then would have greater difficulty keeping up with the additional bandwidth and storage demands. Two equally straightforward mitigations exist to address this if we are given the liberty of modifying the protocol as we wish: 1. Introducing state checkpoints into the chain itself could make it possible for full nodes to skip verification of large sections of historical data when booting up. 2. A sharded protocol, where each shard uses a "sufficiently different" PoW algorithm, would create an exit for users should the primary blockchain become captured by a cartel providing poor quality-of-service. -- Please do not email me anything that you are not comfortable also sharing with the NSA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniele.pinna at gmail.com Mon Feb 19 13:41:21 2018 From: daniele.pinna at gmail.com (Daniele Pinna) Date: Mon, 19 Feb 2018 14:41:21 +0100 Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW In-Reply-To: References: Message-ID: Granted that removing the 21M coin cap is basically a non-starter in de bitcoin community I'd like to respond to a couple points in your proposal. The Y% difficulty adjustment should still be calculated through some averaging of a certain number N of past blocks. Otherwise two lucky high difficulty blocks in a row could potentially grind the network to a halt. Just imagine what would happen to the bitcoin network if the difficulty target was magically increased by 40% all of a sudden. This is certainly not likely but must be considered imo. The second, and most interesting (to me at least) is how the reward should scale with difficulty. By making the reward scale concavely (logarithmically for example) with difficulty as well as depend on past average difficulty AND total # of mined coins, it might be possible to retain something close to the 21M coin cap while also disincentivizing mining blocks with excessively large difficulties. Let D and D_0 be the difficulty of the mind block and some reference initial difficulty respectively. S and S_0 the total floating coin supply and the reference initial supply. Then the reward function could look something like this: R(D, S; D_0,S_0) =R_0(S/S_0)*Log[1+D/D_0]/Log[2] Where R_0(S/S_0) can be some decaying exponential function of the ratio S/S_0 such that initially (when S=S_0) R_0=12.5. But... As I said, this is solely for sake of argument. Daniele ---------- Forwarded message ---------- From: Tao Effect To: Bitcoin Protocol Discussion Cc: Bcc: Date: Sun, 18 Feb 2018 20:29:50 -0500 Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW Copied from: https://github.com/WebOfTrustInfo/rebooting-the- web-of-trust-spring2018/pull/13 # Blockchain Timestamps Unnecessary In Proof-of-Work? *Author: Greg Slepak ([@taoeffect at mastodon.social](https://mastodon.social/@ taoeffect))* ---- The Bitcoin blockchain has a 10-minute target blocktime that is achieved by a difficulty adjustment algorithm. I assert, or rather, pose the hypothesis, that the use of timestamps in Bitcoin's blockchain may be unnecessary, and that Bitcoin can operate with the same security guarantees without it (except as noted in [Risks and Mitigations](#risks-and-mitigations)), and therefore does not need miners to maintain global clock synchronization. The alternative difficulty adjustment algorithm would work according to the following principles: - The incentive for miners is and always has been to maximize profit. - The block reward algorithm is now modified to issue coins into perpetuity (no maximum). Any given block can issue _up to_ `X` number of coins per block. - The number of coins issued per block is now tied directly to the difficulty of the block, and the concept of "epocs" or "block reward halving" is removed. - The chain selection rule remains "chain with most proof of work" - The difficulty can be modified by miners in an arbitrary direction (up or down), but is limited in magnitude by some maximum percentage (e.g. no more than 20% deviation from the previous block), we call this `Y%`. ### Observations - Miners are free to mine blocks of whatever difficulty they choose, up to a maximum deviation - The blockchain may at times produce blocks very quickly, and at other times produce blocks more slowly - Powerful miners are incentivized to raise the difficulty to remove competitors (as is true today) - Whether miners choose to produce blocks quickly or slowly is entirely up to them. If they produce blocks quickly, each block has a lower reward, but there are more of them. If they produce blocks slowly, each block has a higher reward, but there are fewer of them. So an equilibrium will be naturally reached to produce blocks at a rate that should minimize orphans. A timestamp may still be included in blocks, but it no longer needs to be used for anything, or represent anything significant other than metadata about when the miner claims to have produced the block. ### Risks and Mitigations Such a system may introduce risks that require further modification of the protocol to mitigate. The most straightforward risk comes from the potential increase in total transaction throughput that such a change would introduce (these are the same concerns that exist with respect to raising the blocksize). The removal of timestamps would allow a cartel of miners to produce high-difficulty blocks at a fast rate, potentially resulting in additional centralization pressures not only on miners but also on full nodes who then would have greater difficulty keeping up with the additional bandwidth and storage demands. Two equally straightforward mitigations exist to address this if we are given the liberty of modifying the protocol as we wish: 1. Introducing state checkpoints into the chain itself could make it possible for full nodes to skip verification of large sections of historical data when booting up. 2. A sharded protocol, where each shard uses a "sufficiently different" PoW algorithm, would create an exit for users should the primary blockchain become captured by a cartel providing poor quality-of-service. -- Please do not email me anything that you are not comfortable also sharing with the NSA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilansky.sharkson at gmail.com Mon Feb 19 09:21:34 2018 From: ilansky.sharkson at gmail.com (Ilan Oh) Date: Mon, 19 Feb 2018 10:21:34 +0100 Subject: [bitcoin-dev] Built in encryption In-Reply-To: References: Message-ID: Hey guys, Features info, I know we can add text to a btc transaction and it is pretty easy, However is it possible to encrypt the data in a way that only the receiver would be able to read it in clear. And of course without having to exchange info off the network. And if not possible on bitcoin would it be possible on a sidechain or on rsk or else I have few ideas of concrete uses of it, I'm sure you guys may also think of something interesting, Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From lvella at gmail.com Mon Feb 19 20:11:56 2018 From: lvella at gmail.com (Lucas Clemente Vella) Date: Mon, 19 Feb 2018 17:11:56 -0300 Subject: [bitcoin-dev] Built in encryption In-Reply-To: References: Message-ID: Theoretically, if the recipient address had already disclosed the public key (i.e. already spent from that address), or shared it with you instead of (or alongside with) the address, then you can use recipient's ECDSA key to encrypt the message with ECC, as both ECDSA and ECC share the same kind of public/private key pair, according to the this link: https://crypto.stackexchange.com/questions/14662/using-ecdsa-keys-for-encryption In practice, I am not sure the nodes would broadcast such non-standard transaction (but it can be mined, nonetheless). 2018-02-19 6:21 GMT-03:00 Ilan Oh via bitcoin-dev : > Hey guys, > > Features info, > I know we can add text to a btc transaction and it is pretty easy, > > However is it possible to encrypt the data in a way that only the receiver > would be able to read it in clear. > And of course without having to exchange info off the network. > > And if not possible on bitcoin would it be possible on a sidechain or on rsk > or else > > I have few ideas of concrete uses of it, I'm sure you guys may also think of > something interesting, > > Thanks, > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Lucas Clemente Vella lvella at gmail.com From praveen.baratam at gmail.com Tue Feb 20 16:53:25 2018 From: praveen.baratam at gmail.com (Praveen Baratam) Date: Tue, 20 Feb 2018 22:23:25 +0530 Subject: [bitcoin-dev] Multi CSV Transaction Message-ID: Hello Everybody, I need a little clarity about how OP_CHECKSEQUENCEVERIFY (CSV) works in transactions. Can I use multiple CSV end points as depicted in the figure below? I basically want to allow different conditions at different delays. [image: Inline image 3] I just want to know if OP_CHECKSEQUENCEVERIFY can be used to achieve the above. Thank you. Praveen ? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Multi CSV.png Type: image/png Size: 119739 bytes Desc: not available URL: From kanzure at gmail.com Tue Feb 20 22:42:19 2018 From: kanzure at gmail.com (Bryan Bishop) Date: Tue, 20 Feb 2018 16:42:19 -0600 Subject: [bitcoin-dev] Fwd: [Lightning-dev] Post-Schnorr lightning txes In-Reply-To: <20180219225907.GA16444@erisian.com.au> References: <20180219225907.GA16444@erisian.com.au> Message-ID: ---------- Forwarded message ---------- From: Anthony Towns Date: Mon, Feb 19, 2018 at 4:59 PM Subject: [Lightning-dev] Post-Schnorr lightning txes To: lightning-dev at lists.linuxfoundation.org Hi *, My understanding of lightning may be out of date, so please forgive (or at least correct :) any errors on my behalf. I was thinking about whether Greg Maxwell's graftroot might solve the channel monitoring problem (spoiler: not really) and ended up with maybe an interesting take on Schnorr. I don't think I've seen any specific writeup of what that might look like, so hopefully at least some of this is novel! I'm assuming familiarity with current thinking on Schnorr sigs -- but all you should need to know is the quick summary at footnote [0]. So I think there's four main scenarios for closing a lightning channel: - both parties are happy to close, do so cooperatively, and can sign a new unconditional transaction that they agree on. already fine. (should happen almost all of the time, call it 80%) - communications failure: one side has to close, but the other side is happy to cooperate as far as they're able but can only do so via the blockchain and maybe with some delay (maybe 15% of the time) - disappearance, uncooperative: one side effectively completely disappears so the other side has to fully close the channel on their own (5% of the time) - misbehaviour: one side tries publishing an old channel state due to error or maliciousness, and the other collects the entire balance as penalty (0% of the time) With "graftroot" in mind, I was thinking that optimising for the last case might be interesting -- despite expecting it to be vanishingly rare. That would have to look something like: (0) funding tx (1) ...which is spent by a misbehaving commitment tx (2) ...which is spent by a penalty tx You do need 3 txes for that case, but you really only need 1 output for each: so (0) is 2-in-1-out, (1) is 1-in-1-out, (2) is 1-in-1-out; which could all be relatively cheap. (And (2) could be batched with other txes making it 1 input in a potentially large tx) For concreteness, I'm going to treat A as the one doing the penalising, and B (Bad?) as the one that's misbehaving. If you treat each of those txes as a muSig Schnorr pay-to-pubkey, the output addresses would be: (0) funding tx pays to [A,B] (1) commitment tx pays to [A(i),Revocation(B,i)] (2) pays to A (where i is a commitment id / counter for the channel state) If B misbehaves by posting the commitment tx after revealing the revocation secret, A can calculate A(i) and Revocation(B,i) and claim all the funds immediately. As far as the other cases go: - In a cooperative close, you don't publish any commitment txes, you just spend the funding to each party's preferred destinations directly; so this is already great. - Otherwise, you need to be able to actually commit to how the funds get distributed. But committing to distributing funds is easy: just jointly sign a transaction with [A(i),Revocation(B,i)]. Since B is the one we're worrying about misbehaving, it needs to hold a transaction with the appropriate outputs that is: - timelocked to `to_self_delay` blocks/seconds in advance via nSequence - signed by A(i) That ensures A has `to_self_delay` blocks/seconds to penalise misehaviour, and that when closing properly, B can complete the signature using the current revocation secret. This means the "appropriate outputs" no longer need the OP_CSV step, which should simplify the scripts a bit. Having B have a distribution transaction isn't enough -- B could vanish between publishing the commitment transaction and the distribution transaction, leaving A without access to any funds. So A needs a corresponding distribution transaction. But because that transaction can only be published if B signs and publishes the corresponding commitment transaction, the fact that it's published indicates both A and B are happy with the channel close -- so this is a semi-cooperative close and no delay is needed. So A should hold a partially signed transaction with the same outputs: - without any timelock - signed by Revocation(B,i), waiting for signature by A(i) Thus, if B does a non-cooperative close, either: - A proves misbehaviour and claims all the funds immediately - A agrees that the channel state is correct, signs and publishes the un-timelocked distribution transaction, then claims A's outputs; B can then immediately claim its outputs - A does nothing, and B waits for the `to_self_delay` period, signs and publishes its transaction, then claims B's outputs; A can eventually claim its own outputs In that case all of the transactions except the in-flight HTLCs just look like simple pay-to-pubkey transactions. Further, other than the historical secrets no old information needs to be retained: misbehaviour can be dealt with (and can only be dealt with) by creating a new transaction signed by your own secrets and the revocation information. None of that actually relies on Schnorr-multisig, I think -- it could be done today with normal 2-of-2 multisig as far as I can see. I'm not 100% sure how this approach works compared to the current one for the CSV/CLTV overlap problem. I think any case you could solve by obtaining a HTLC-Timeout or HTLC-Success transaction currently, you could solve in the above scenario by just updating the channel state to remove the HTLC. So I believe the above lets you completely forget info about old HTLCs, while still enforcing correct behavior, and also makes enforcing correct behaviour cheaper because it's just two extremely simple transactions to post. If I haven't missed any corner cases, it also seems to simplify the scripts a fair bit. Does this make sense? It seems to to me... So for completeness, it would make sense to do HTLCs via Schnorr -- at least to make them reveal elliptic curve private keys, and ideally to make them mostly indistinguishable from regular transactions as a "scriptless script" [1] or "discreet log contract" [2]. (I think, at least for HTLCs, these end up being the same?) The idea then is to have the HTLC payment hash be R=r*G, where r is the secret/payment receipt. Supposing your current commitment has n HTLCs in-flight, some paying A if the HTLC succeeds and "r" is revealed, others paying B. We'll focus on one paying A. So you succeed by A completing a signature that reveals r to B, and which simultaneously allows collection of the funds on chain. A needs to be able to do this knowing nothing other than r (and their own private keys). So agree to sign to muSig 2-of-2 multisig [A,B]. A and B generate random values i and j respectively and reveal I=i*G and J=j*G, and each calculates Q=I+J+R, and they generate partial signatures of a transaction paying A: I, i + H(X,Q,m)*H(L,A)*a J, j + H(X,Q,m)*H(L,B)*b where L = H(A,B) and X = H(L,A)*A + H(L,B)*B as usual. Once A knows r, A can construct a full signature by adding R, r to the above values, and B can then determine r by subtracting the above values from signature A generated. To ensure B gets paid if the HTLC timesout, they should also sign a timelocked transaction paying B directly, that B can hold onto until the channel state gets updated. And once you're doing payment hashes via ECC, you can of course change them at each hop to make it harder to correlate steps in a payment route. I think that when combined with the above method of handling CSV delays and revocation, this covers all the needed cases with a straightforward pay-to-pubkey(hash) output, no script info needed at all. It does mean each HTLC needs a signature every time the channel state updates (B needs to sign a tx allowing A to claim the output once A knows the secret, A needs to sign a tx allowing B to claim the output on timeout). For channel monitoring this is pretty good, I think. You need to keep track of the revocation info and your secret keys -- but that's essentially a constant amount of data. If you're happy to have the data grow by 64 bytes every time the channel state updates, you can outsource channel monitoring: arrange a formula for constructing a penalty tx based on the channel commitment tx -- eg, 95% of the balance goes to me, 4% goes to the monitor's address, 1% goes to fees, there's a relative locktime of to_self_delay/3 to allow me to directly claim 100% of the funds if I happen to be paying attention; then do a partial signature with A(i), and then allow the monitoring service to catch fraudulent transactions, work out the appropriate revocation secret, and finish the signature. If your channel updates 100 times a second for an entire year, that's 200GB of data, which seems pretty feasible. (You can't just regenerate that data though, unless you keep each commitment tx) And it's pretty easy to work out which bit of data you need to access: the funding tx that's being spent tells you which channel, and the channel state index is encoded in the locktime and sequence, so you should only need small/logarithmic overhead even for frequently updated channels rather than any serious indexes. I don't think you can do better than that without serious changes to bitcoin: if you let the monitoring agency sign on its own, you'd need some sort of covenant opcode to ensure it sends any money to you; and with segwit outputs, there's no way to provide a signature for a transaction without committing to exactly which transaction you're signing. I was hoping covenants and graftroot would be enough, but I don't think they are. The idea would be that since the transaction spends to A(i)+Rev(B,i), you'd sign an output script with A that uses covenant opcodes to ensure the transaction only pays the appropriate monitoring reward, and the monitor could then work out A(i)-A and Rev(B,i) and finish the signature. But the signature by "A" would need to know A(i)+Rev(B,i) when calculating the hash, and that's different for every commitment transaction, so as far as I can see, it just doesn't work. You can't drop the muSig-style construction because you need to be protect yourself against potential malicious choice of the revocation secret [3]. Summary: - Funding txes as 2-of-2 multisig is still great. Convert to Schnorr/muSig when available of course. - Generate 6+8*n transactions everytime the channel state is updated, (n = number of HTLCs in-flight) 1. Channel state commitment tx, held by A, spends funding tx, payable to Schnorr muSig address [A(i),Rev(B,i)], signed by B 2. Channel fund distribution tx, held by A (CSV), spends (1), signed by Rev(B,i) 3. Channel fund distribution tx, held by B (no CSV), spends (1), signed by A(i) 4. Channel state commitment tx, held by B, spends funding tx payable to Schnorr muSig address [B(i),Rev(A,i)], signed by A 5. Channel fund distribution tx, held by B (CSV), spends (4), signed by Rev(A,i) 6. Channel fund distribution tx, held by A (no CSV), spends (4), signed by B(i) The fund distribution txs all pay the same collection of addresses: - channel balance for A directly to A's preferred address - channel balance for B directly to B's preferred address - HTLC balance to muSig address for [A,B] for each in-flight HTLC paying A on success - HTLC balance to muSig address for [B,A] for each in-flight HTLC paying B on success - (probably makes sense to bump the HTLC addresses by some random value to make it harder for third parties to tell which addresses were balances versus HTLCs) Both (1) and (4) include obscured channel state ids as per current standard. For each HTLC that pays X on timeout and Y on success: a. Timeout tx, held by X, signed by Y, spends from (2) b. Timeout tx, held by X, signed by Y, spends from (3) c. Timeout tx, held by X, signed by Y, spends from (5) d. Timeout tx, held by X, signed by Y, spends from (6) e. Success tx, held by Y, signed by X, spends from (2) f. Success tx, held by Y, signed by X, spends from (3) g. Success tx, held by Y, signed by X, spends from (5) h. Success tx, held by Y, signed by X, spends from (6) (these should all be able to be SIGHASH_SINGLE, ANYONECANPAY to allow some level of aggregation) - Fund distribution tx outputs can all be pay2pubkey(hash): HTLCs work by pre-signed timelocked transactions and scriptless scripts/discreet-log contracts to reveal the secret; balances work directly; CSV and revocations are already handled by that point - You can discard all old transaction info and HTLC parameters once they're not relevant to the current channel state - Channel monitoring can be outsourced pretty efficiently -- as little as a signature per state could be made to works as far as I can see, which doesn't add up too fast. - There's still no plausible way of doing constant space outsourced channel monitoring without some sort of SIGHASH_NOINPUT, at least that I can see Thoughts? [4] Cheers, aj, very sad that this didn't turn out to be a potential use case for graftroot :( [0] In particular, I'm assuming that: - Schnorr sigs in bitcoin will look something like: R, r + H(X,R,m)*x (where m is the message being signed by private key x, r is a random per-sig nonce, R and X are public keys corresponding to r,x; H is the secure hash function) - muSig is a secure way for untrusting parties to construct an n-of-n combined signature; for public keys A and B, it produces a combined public key: X = H(L,A)*A + H(L,B)*B with L = H(A,B) See https://blockstream.com/2018/01/23/musig-key-aggregation- schnorr-signatures.html [1] https://scalingbitcoin.org/stanford2017/Day2/Using-the- Chain-for-what-Chains-are-Good-For.pdf http://diyhpl.us/wiki/transcripts/scalingbitcoin/ stanford-2017/using-the-chain-for-what-chains-are-good-for/ [2] https://adiabat.github.io/dlc.pdf https://diyhpl.us/wiki/transcripts/discreet-log-contracts/ [3] Well, maybe you could request a zero-knowledge proof to ensure a new revocation hash conforms to the standard for generating revocation secrets without revealing the secret, and have the public key be a(i)*G + r(B,i)*G without using the muSig construct, but that would probably be obnoxious to have to generate every time you update the channel state. [4] As an aside -- this could make it feasible and interesting to penalise disappearance as well as misbehaviour. If you add a transaction the B pre-signs, spending the commitment tx A holds, giving all the channel funds to A but only after a very large CSV timeout, perhaps `to_self_delay`*50, then the scenarios are: If A is present: - B publishes an old commitment: A immediately steals all the funds if active or outsourced misbehaviour monitoring. Whoops! - B publishes the current commitment: A publishes its distribution transaction and collects its funds immediately, allowing B to do likewise If A has disappeared: - B publises the current commitment and waits a modest amount of time, publishes its distribution transaction claiming its rightful funds, and allowing A to collect its funds if it ever does reappear and still knows its secrets - B publishes the current commitment, waits a fair while, A reappears and publishes its distribution transactions, both parties get their rightful funds - B publishes the current commitment, waits an extended period of time, and claims the entire channel's funds. If B is particularly reputable, and A can prove its identity (but not recover all its secrets) maybe B even refunds A some/all of its rightful balance Perhaps that provides too much of an incentive to try blocking someone from having access to the blockchain though. _______________________________________________ Lightning-dev mailing list Lightning-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev -- - Bryan http://heybryan.org/ 1 512 203 0507 -------------- next part -------------- An HTML attachment was scrubbed... URL: From danrobinson010 at gmail.com Wed Feb 21 00:59:45 2018 From: danrobinson010 at gmail.com (Daniel Robinson) Date: Wed, 21 Feb 2018 00:59:45 +0000 Subject: [bitcoin-dev] Multi CSV Transaction In-Reply-To: References: Message-ID: Yes, although it's a functionality of Bitcoin Script generally, not OP_CSV in particular. Bitcoin Script allows you to use nested IF statements, and enforce whatever different conditions you want in each branch. Here's your contract in Ivy : contract MultiCSV( bob: PublicKey, carol: PublicKey, bobDelay: Duration, carolDelay: Duration, val: Value ) { clause bobSpend(sig: Signature) { verify checkSig(bob, sig) verify older(bobDelay) unlock val } clause carolSpend(sig: Signature) { verify checkSig(carol, sig) verify older(carolDelay) unlock val } clause bothSpend(bobSig: Signature, carolSig: Signature) { verify checkMultiSig([bob, carol], [bobSig, carolSig]) unlock val } } It compiles to the following Bitcoin Script: PUSH(carolKey) PUSH(bobKey) 2 PICK 2 EQUAL IF ROT DROP 0 4 ROLL 4 ROLL 2 2ROT 2 CHECKMULTISIG ELSE ROT IF DROP CHECKSIGVERIFY PUSH(carolDelay) CHECKSEQUENCEVERIFY DROP 1 ELSE NIP CHECKSIGVERIFY PUSH(bobDelay) CHECKSEQUENCEVERIFY DROP 1 ENDIF ENDIF On Tue, Feb 20, 2018 at 5:32 PM Praveen Baratam via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > Hello Everybody, > > I need a little clarity about how OP_CHECKSEQUENCEVERIFY (CSV) works in > transactions. > > Can I use multiple CSV end points as depicted in the figure below? I > basically want to allow different conditions at different delays. > > [image: Multi CSV.png] > > I just want to know if OP_CHECKSEQUENCEVERIFY can be used to achieve the > above. > > Thank you. > > Praveen > ? > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Multi CSV.png Type: image/png Size: 119739 bytes Desc: not available URL: From praveen.baratam at gmail.com Wed Feb 21 02:36:31 2018 From: praveen.baratam at gmail.com (Praveen Baratam) Date: Wed, 21 Feb 2018 08:06:31 +0530 Subject: [bitcoin-dev] Multi CSV Transaction In-Reply-To: References: Message-ID: Thank you Daniel! Your detailed explanation did clear things up :-) ? On Wed, Feb 21, 2018 at 6:29 AM, Daniel Robinson wrote: > Yes, although it's a functionality of Bitcoin Script generally, not OP_CSV > in particular. Bitcoin Script allows you to use nested IF statements, and > enforce whatever different conditions you want in each branch. > > Here's your contract in Ivy : > > contract MultiCSV( > bob: PublicKey, > carol: PublicKey, > bobDelay: Duration, > carolDelay: Duration, > val: Value > ) { > clause bobSpend(sig: Signature) { > verify checkSig(bob, sig) > verify older(bobDelay) > unlock val > } > clause carolSpend(sig: Signature) { > verify checkSig(carol, sig) > verify older(carolDelay) > unlock val > } > clause bothSpend(bobSig: Signature, carolSig: Signature) { > verify checkMultiSig([bob, carol], [bobSig, carolSig]) > unlock val > } > } > > It compiles to the following Bitcoin Script: > > PUSH(carolKey) PUSH(bobKey) 2 PICK 2 EQUAL IF ROT DROP 0 4 ROLL 4 ROLL 2 > 2ROT 2 CHECKMULTISIG ELSE ROT IF DROP CHECKSIGVERIFY PUSH(carolDelay) > CHECKSEQUENCEVERIFY DROP 1 ELSE NIP CHECKSIGVERIFY PUSH(bobDelay) > CHECKSEQUENCEVERIFY DROP 1 ENDIF ENDIF > > On Tue, Feb 20, 2018 at 5:32 PM Praveen Baratam via bitcoin-dev < > bitcoin-dev at lists.linuxfoundation.org> wrote: > >> Hello Everybody, >> >> I need a little clarity about how OP_CHECKSEQUENCEVERIFY (CSV) works in >> transactions. >> >> Can I use multiple CSV end points as depicted in the figure below? I >> basically want to allow different conditions at different delays. >> >> [image: Multi CSV.png] >> >> I just want to know if OP_CHECKSEQUENCEVERIFY can be used to achieve the >> above. >> >> Thank you. >> >> Praveen >> ? >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > -- Dr. Praveen Baratam about.me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Multi CSV.png Type: image/png Size: 119739 bytes Desc: not available URL: From eric at voskuil.org Wed Feb 21 17:27:53 2018 From: eric at voskuil.org (Eric Voskuil) Date: Wed, 21 Feb 2018 09:27:53 -0800 Subject: [bitcoin-dev] Amend the BIP 123 process to include buried deployments In-Reply-To: References: <8fb2e424-268c-7433-5f6b-5fbab5c5cc5c@voskuil.org> Message-ID: <458f13b8-ab09-400f-b5cb-c6fa42726244@voskuil.org> On 02/18/2018 10:57 AM, Marco Falke via bitcoin-dev wrote: >> They also do not require software coordination. Therefore, why should there be >> BIPs at all? Seems to me that we should instead add these documents to >> https://github.com/bitcoin-core/docs > > Consensus is not trivial. I think documentation is important, even if > it seems simple to some. > Personally, I don't care too much where to place the documentation, > but the BIPs repo seems a good place, since it also hosts other > informational documents. > > To prevent "two BIPs for every protocol change", related buried > deployments could be bundled. E.g. the ISM BIP 90 change. You seem to have missed the point. Either the "buried deployment" is a consensus rule, and requires a BIP, or it is not a consensus rule, and does not warrant a BIP. You are arguing that it is not a consensus rule, yet requires a BIP. You also strongly imply that it is a consensus rule ("consensus is important"). If it is a consensus rule it is either a hard fork (valid tx set expansion) or a soft fork (valid tx set contraction). You are attempting to create an independent category that violates this clear engineering definition. The category you desire is actually a subcategory of hard fork (employing an arbitrary threshold for likelihood of causing a chain split). > On Wed, Feb 14, 2018 at 6:57 PM, Eric Voskuil wrote: >> On 02/14/2018 02:01 PM, Marco Falke via bitcoin-dev wrote: >>> I define a buried deployment as a consensus rule change that affects >>> validity of blocks that are buried by a sufficiently large number of >>> blocks in the current valid most-work chain, >> >> Sufficient for what, specifically? > > Sufficiently large to prevent potential bike-shedding. The expected > number of blocks in two weeks could be considered a lower bound. Then > multiply that by 10 or 20. The arbitrary threshold. It seems it could be anything. Such a definition has no clear *engineering* usefulness. >>> but the current block (and all its parents) remain valid. >> >> Remain valid in the case where the depth assumption is "sufficient" to >> ensure that a chain split is not possible? >> >> If this was true (which it is not), it would imply that there is no >> reason to validate any block deeper than the most recent 25,000. >> Presumably this means that people may continuously rely on some >> authority (like Bitcoin Core?) to determine the checkpoint for tip-25,000. >> > Note that a checkpoint *freezes* the chain completely at a given > height. Buried deployments are *not* checkpoints. You are arguing a point that I did not make. The issue is that you argue a "buried deployment" hard fork cannot create a chain split. This itself implies that the chain is "frozen" at the depth below which the chain cannot be split. In other words, by accepting your logic, we must conclude there is no reason whatsoever to validate the chain prior to that depth. This would lead to the conclusion that check-pointing the chain to that depth is always sufficient validation. > Also note that buried deployments only make sense after a protocol > upgrade has happened (i.e. a soft fork or hard fork). If a miner has > the resources to cause a chain split, they could trivially do that > even in the complete absence of buried deployments. Buried deployments > are *not* a solution to 50% attacks. Not sure why you are making this obvious but seemingly-irrelevant point. >>> BIP 123 suggests that BIPs in the consensus layer should be assigned a >>> label "soft fork" or "hard fork". However, I think the differentiation >>> into soft fork or hard fork should not be made for BIPs that document >>> buried deployments. In contrast to soft forks and hard forks, buried >>> deployments do not require community and miner coordination for a safe >>> deployment. >> >> They can only avoid this requirement based on the assumption that the >> hard fork cannot result in a chain split. This is not the case. >> >>> For a chain fork to happen due to a buried deployment, a massive chain >>> reorganization must be produced off of a block in the very past. >> >> In other words a "buried deployment" is a hard fork that is not likely >> to cause a chain split. This is a subjective subcategory of hard fork, >> not an independent category - unless maybe you can show that there is >> the 25,000 blocks number is an objective threshold. > > Please note that a buried deployment can very well be a soft fork. I > think this makes it even clearer, that such a label makes no sense for > buried deployments. No, it cannot. Removal of an activated soft fork (valid tx set contraction) is a hard fork (valid tx set expansion), and a new activation rule for an active soft fork creates a path to that removal. Given this error you may want to reconsider your proposal. >>> In the extremely unlikely event of such a large chain reorganization, >>> Bitcoin's general security assumptions would be violated regardless of >>> the presence of a buried deployment. >> >> This is untrue. The "security assumptions" of Bitcoin do not preclude >> deep reorganizations. >> >> e -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: OpenPGP digital signature URL: From contact at taoeffect.com Wed Feb 21 21:58:10 2018 From: contact at taoeffect.com (Tao Effect) Date: Wed, 21 Feb 2018 16:58:10 -0500 Subject: [bitcoin-dev] Some thoughts on removing timestamps in PoW In-Reply-To: References: <0899818B-4A48-4A88-8624-B0B6F9536734@taoeffect.com> Message-ID: > What you are suggesting, unless I am mistaken, is that new full nodes should have no way of knowing if an output is spent or even if it exists. Since large sections of the blockchain will potentially be skipped, the full node will not have complete knowledge of utxo's just for starters. So, this might not have been clear, but by "if we are given the liberty of modifying the protocol as we wish" I meant that I was discussing a protocol where these sorts of concerns are not an issue because we are not limited by the constraints of Bitcoin's current design. There have been plenty of proposals across the web for how to design a blockchain where what you're referring to is not an issue because of merkle commitments, etc., and some blockchains already do this (e.g. I believe Ethereum does this via parity). Cheers, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. > On Feb 19, 2018, at 4:04 AM, Damian Williamson wrote: > > >1. Introducing state checkpoints into the chain itself could make it possible for full nodes to skip verification of large sections of historical data when booting up. > > What you are suggesting, unless I am mistaken, is that new full nodes should have no way of knowing if an output is spent or even if it exists. Since large sections of the blockchain will potentially be skipped, the full node will not have complete knowledge of utxo's just for starters. > > Regards, > Damian Williamson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From bitcoin-dev at rgrant.org Thu Feb 22 12:19:36 2018 From: bitcoin-dev at rgrant.org (Ryan Grant) Date: Thu, 22 Feb 2018 12:19:36 +0000 Subject: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption In-Reply-To: References: Message-ID: On Fri, Feb 9, 2018 at 7:29 AM, Jeremy wrote: > utility of this construction can be improved if we introduce functionality > that makes a script invalid after a certain time Tagging this thread with "nExpiryTime". Search archives for more. From esotericnonsense at esotericnonsense.com Thu Feb 22 19:44:21 2018 From: esotericnonsense at esotericnonsense.com (Daniel Edgecumbe) Date: Thu, 22 Feb 2018 11:44:21 -0800 Subject: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption In-Reply-To: References: Message-ID: <1519328661.898070.1280084352.71F1C1C3@webmail.messagingengine.com> > However, the non-interactive schnorr aggregation trick[1] can be applied to merge the S values of all graftroots and signatures in a transaction into a single aggregate. With this approach only a single R value for each graftroot need be published, lowering the overhead to ~32 bytes-- the same as taproot. This has a side benefit of binding the published grafts to a particular transaction, which might help avoid some screwups. I don't think that binding grafts to a particular transaction requires this aggregation. It seems to me that you could just sign H(txid, script) rather than H(script). I'm not aware of whether this would break aggregation. --- Daniel Edgecumbe / esotericnonsense esotericnonsense at esotericnonsense.com https://esotericnonsense.com https://danedgecumbe.com From willtech at live.com.au Sat Feb 24 06:00:48 2018 From: willtech at live.com.au (Damian Williamson) Date: Sat, 24 Feb 2018 06:00:48 +0000 Subject: [bitcoin-dev] BIP Activation Reference Message-ID: Would it be possible or desirable to add a `nBlockHeight Activated` column to the [README.mediawiki](https://github.com/bitcoin/bips/blob/master/README.mediawiki) to show a specific reference to when a BIP was activated? - And/or include such information in the BIP Header format? Regards, Damian Williamson -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at xiph.org Sat Feb 24 18:58:59 2018 From: greg at xiph.org (Gregory Maxwell) Date: Sat, 24 Feb 2018 18:58:59 +0000 Subject: [bitcoin-dev] Graftroot: Private and efficient surrogate scripts under the taproot assumption In-Reply-To: <1519328661.898070.1280084352.71F1C1C3@webmail.messagingengine.com> References: <1519328661.898070.1280084352.71F1C1C3@webmail.messagingengine.com> Message-ID: On Thu, Feb 22, 2018 at 7:44 PM, Daniel Edgecumbe via bitcoin-dev wrote: > I don't think that binding grafts to a particular transaction requires this aggregation. > It seems to me that you could just sign H(txid, script) rather than H(script). > I'm not aware of whether this would break aggregation. That would require that you know the txid in advance. Sometimes you do-- and a graftroot sighash flag could handle that... but usually you wouldn't. The case where you already do know it can sort of be covered today without using the graftroot: Sign a transaction spending the multisig coin to the graft. This isn't a strict alternative however, because it's not atomic: you could imagine that txn being announced and then the graft not being spent, while someone would like to spend a different graft. That non-atomiticity could be addressed by making the graft spends an OR of all the other graft spends but that isn't scalable or private. Regardless, still doesn't work if the graft isn't created after the fact. The aggregation bit has the property of working just in time, even on grafts created in advance. From laanwj at gmail.com Mon Feb 26 07:54:17 2018 From: laanwj at gmail.com (Wladimir J. van der Laan) Date: Mon, 26 Feb 2018 08:54:17 +0100 Subject: [bitcoin-dev] Bitcoin Core 0.16.0 released Message-ID: <20180226075417.GA13544@amethyst.visucore.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Bitcoin Core version 0.16.0 is now available from: or through bittorrent: magnet:?xt=urn:btih:6493ae7a15b4d32bb4eca1dfaf6dcc0c143492cb&dn=bitcoin-core-0.16.0&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969 This is a new major version release, including new features, various bugfixes and performance improvements, as well as updated translations. Please report bugs using the issue tracker at GitHub: To receive security and update notifications, please subscribe to: How to Upgrade ============== If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac) or `bitcoind`/`bitcoin-qt` (on Linux). The first time you run version 0.15.0 or newer, your chainstate database will be converted to a new format, which will take anywhere from a few minutes to half an hour, depending on the speed of your machine. Note that the block database format also changed in version 0.8.0 and there is no automatic upgrade code from before version 0.8 to version 0.15.0 or higher. Upgrading directly from 0.7.x and earlier without re-downloading the blockchain is not supported. However, as usual, old wallet versions are still supported. Downgrading warning - ------------------- Wallets created in 0.16 and later are not compatible with versions prior to 0.16 and will not work if you try to use newly created wallets in older versions. Existing wallets that were created with older versions are not affected by this. Compatibility ============== Bitcoin Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not supported. Bitcoin Core should also work on most other Unix-like systems but is not frequently tested on them. Notable changes =============== Wallet changes - --------------- ### Segwit Wallet Bitcoin Core 0.16.0 introduces full support for segwit in the wallet and user interfaces. A new `-addresstype` argument has been added, which supports `legacy`, `p2sh-segwit` (default), and `bech32` addresses. It controls what kind of addresses are produced by `getnewaddress`, `getaccountaddress`, and `createmultisigaddress`. A `-changetype` argument has also been added, with the same options, and by default equal to `-addresstype`, to control which kind of change is used. A new `address_type` parameter has been added to the `getnewaddress` and `addmultisigaddress` RPCs to specify which type of address to generate. A `change_type` argument has been added to the `fundrawtransaction` RPC to override the `-changetype` argument for specific transactions. - - All segwit addresses created through `getnewaddress` or `*multisig` RPCs explicitly get their redeemscripts added to the wallet file. This means that downgrading after creating a segwit address will work, as long as the wallet file is up to date. - - All segwit keys in the wallet get an implicit redeemscript added, without it being written to the file. This means recovery of an old backup will work, as long as you use new software. - - All keypool keys that are seen used in transactions explicitly get their redeemscripts added to the wallet files. This means that downgrading after recovering from a backup that includes a segwit address will work Note that some RPCs do not yet support segwit addresses. Notably, `signmessage`/`verifymessage` doesn't support segwit addresses, nor does `importmulti` at this time. Support for segwit in those RPCs will continue to be added in future versions. P2WPKH change outputs are now used by default if any destination in the transaction is a P2WPKH or P2WSH output. This is done to ensure the change output is as indistinguishable from the other outputs as possible in either case. ### BIP173 (Bech32) Address support ("bc1..." addresses) Full support for native segwit addresses (BIP173 / Bech32) has now been added. This includes the ability to send to BIP173 addresses (including non-v0 ones), and generating these addresses (including as default new addresses, see above). A checkbox has been added to the GUI to select whether a Bech32 address or P2SH-wrapped address should be generated when using segwit addresses. When launched with `-addresstype=bech32` it is checked by default. When launched with `-addresstype=legacy` it is unchecked and disabled. ### HD-wallets by default Due to a backward-incompatible change in the wallet database, wallets created with version 0.16.0 will be rejected by previous versions. Also, version 0.16.0 will only create hierarchical deterministic (HD) wallets. Note that this only applies to new wallets; wallets made with previous versions will not be upgraded to be HD. ### Replace-By-Fee by default in GUI The send screen now uses BIP125 RBF by default, regardless of `-walletrbf`. There is a checkbox to mark the transaction as final. The RPC default remains unchanged: to use RBF, launch with `-walletrbf=1` or use the `replaceable` argument for individual transactions. ### Wallets directory configuration (`-walletdir`) Bitcoin Core now has more flexibility in where the wallets directory can be located. Previously wallet database files were stored at the top level of the bitcoin data directory. The behavior is now: - - For new installations (where the data directory doesn't already exist), wallets will now be stored in a new `wallets/` subdirectory inside the data directory by default. - - For existing nodes (where the data directory already exists), wallets will be stored in the data directory root by default. If a `wallets/` subdirectory already exists in the data directory root, then wallets will be stored in the `wallets/` subdirectory by default. - - The location of the wallets directory can be overridden by specifying a `-walletdir=` option where `` can be an absolute path to a directory or directory symlink. Care should be taken when choosing the wallets directory location, as if it becomes unavailable during operation, funds may be lost. Build: Minimum GCC bumped to 4.8.x - ------------------------------------ The minimum version of the GCC compiler required to compile Bitcoin Core is now 4.8. No effort will be made to support older versions of GCC. See discussion in issue #11732 for more information. The minimum version for the Clang compiler is still 3.3. Other minimum dependency versions can be found in `doc/dependencies.md` in the repository. Support for signalling pruned nodes (BIP159) - --------------------------------------------- Pruned nodes can now signal BIP159's NODE_NETWORK_LIMITED using service bits, in preparation for full BIP159 support in later versions. This would allow pruned nodes to serve the most recent blocks. However, the current change does not yet include support for connecting to these pruned peers. Performance: SHA256 assembly enabled by default - ------------------------------------------------- The SHA256 hashing optimizations for architectures supporting SSE4, which lead to ~50% speedups in SHA256 on supported hardware (~5% faster synchronization and block validation), have now been enabled by default. In previous versions they were enabled using the `--enable-experimental-asm` flag when building, but are now the default and no longer deemed experimental. GUI changes - ----------- - - Uses of "?BTC" in the GUI now also show the more colloquial term "bits", specified in BIP176. - - The option to reuse a previous address has now been removed. This was justified by the need to "resend" an invoice, but now that we have the request history, that need should be gone. - - Support for searching by TXID has been added, rather than just address and label. - - A "Use available balance" option has been added to the send coins dialog, to add the remaining available wallet balance to a transaction output. - - A toggle for unblinding the password fields on the password dialog has been added. RPC changes - ------------ ### New `rescanblockchain` RPC A new RPC `rescanblockchain` has been added to manually invoke a blockchain rescan. The RPC supports start and end-height arguments for the rescan, and can be used in a multiwallet environment to rescan the blockchain at runtime. ### New `savemempool` RPC A new `savemempool` RPC has been added which allows the current mempool to be saved to disk at any time to avoid it being lost due to crashes / power loss. ### Safe mode disabled by default Safe mode is now disabled by default and must be manually enabled (with `-disablesafemode=0`) if you wish to use it. Safe mode is a feature that disables a subset of RPC calls - mostly related to the wallet and sending - automatically in case certain problem conditions with the network are detected. However, developers have come to regard these checks as not reliable enough to act on automatically. Even with safe mode disabled, they will still cause warnings in the `warnings` field of the `getneworkinfo` RPC and launch the `-alertnotify` command. ### Renamed script for creating JSON-RPC credentials The `share/rpcuser/rpcuser.py` script was renamed to `share/rpcauth/rpcauth.py`. This script can be used to create `rpcauth` credentials for a JSON-RPC user. ### Validateaddress improvements The `validateaddress` RPC output has been extended with a few new fields, and support for segwit addresses (both P2SH and Bech32). Specifically: * A new field `iswitness` is True for P2WPKH and P2WSH addresses ("bc1..." addresses), but not for P2SH-wrapped segwit addresses (see below). * The existing field `isscript` will now also report True for P2WSH addresses. * A new field `embedded` is present for all script addresses where the script is known and matches something that can be interpreted as a known address. This is particularly true for P2SH-P2WPKH and P2SH-P2WSH addresses. The value for `embedded` includes much of the information `validateaddress` would report if invoked directly on the embedded address. * For multisig scripts a new `pubkeys` field was added that reports the full public keys involved in the script (if known). This is a replacement for the existing `addresses` field (which reports the same information but encoded as P2PKH addresses), represented in a more useful and less confusing way. The `addresses` field remains present for non-segwit addresses for backward compatibility. * For all single-key addresses with known key (even when wrapped in P2SH or P2WSH), the `pubkey` field will be present. In particular, this means that invoking `validateaddress` on the output of `getnewaddress` will always report the `pubkey`, even when the address type is P2SH-P2WPKH. ### Low-level changes - - The deprecated RPC `getinfo` was removed. It is recommended that the more specific RPCs are used: * `getblockchaininfo` * `getnetworkinfo` * `getwalletinfo` * `getmininginfo` - - The wallet RPC `getreceivedbyaddress` will return an error if called with an address not in the wallet. - - The wallet RPC `addwitnessaddress` was deprecated and will be removed in version 0.17, set the `address_type` argument of `getnewaddress`, or option `-addresstype=[bech32|p2sh-segwit]` instead. - - `dumpwallet` now includes hex-encoded scripts from the wallet in the dumpfile, and `importwallet` now imports these scripts, but corresponding addresses may not be added correctly or a manual rescan may be required to find relevant transactions. - - The RPC `getblockchaininfo` now includes an `errors` field. - - A new `blockhash` parameter has been added to the `getrawtransaction` RPC which allows for a raw transaction to be fetched from a specific block if known, even without `-txindex` enabled. - - The `decoderawtransaction` and `fundrawtransaction` RPCs now have optional `iswitness` parameters to override the heuristic witness checks if necessary. - - The `walletpassphrase` timeout is now clamped to 2^30 seconds. - - Using addresses with the `createmultisig` RPC is now deprecated, and will be removed in a later version. Public keys should be used instead. - - Blockchain rescans now no longer lock the wallet for the entire rescan process, so other RPCs can now be used at the same time (although results of balances / transactions may be incorrect or incomplete until the rescan is complete). - - The `logging` RPC has now been made public rather than hidden. - - An `initialblockdownload` boolean has been added to the `getblockchaininfo` RPC to indicate whether the node is currently in IBD or not. - - `minrelaytxfee` is now included in the output of `getmempoolinfo` Other changed command-line options - ---------------------------------- - - `-debuglogfile=` can be used to specify an alternative debug logging file. - - bitcoin-cli now has an `-stdinrpcpass` option to allow the RPC password to be read from standard input. - - The `-usehd` option has been removed. - - bitcoin-cli now supports a new `-getinfo` flag which returns an output like that of the now-removed `getinfo` RPC. Testing changes - ---------------- - - The default regtest JSON-RPC port has been changed to 18443 to avoid conflict with testnet's default of 18332. - - Segwit is now always active in regtest mode by default. Thus, if you upgrade a regtest node you will need to either -reindex or use the old rules by adding `vbparams=segwit:0:999999999999` to your regtest bitcoin.conf. Failure to do this will result in a CheckBlockIndex() assertion failure that will look like: Assertion `(pindexFirstNeverProcessed != nullptr) == (pindex->nChainTx == 0)' failed. 0.16.0 change log - ------------------ ### Block and transaction handling - - #10953 `aeed345` Combine scriptPubKey and amount as CTxOut in CScriptCheck (jl2012) - - #11309 `93d20a7` Minor cleanups for AcceptToMemoryPool (morcos) - - #11418 `38c201f` Add error string for CLEANSTACK script violation (maaku) - - #11411 `339da9c` Change SignatureHash input index check to an assert (jimpo) - - #11406 `e12522d` Add state message print to AcceptBlock failure message (TheBlueMatt) - - #11062 `26fee4f` Mark mempool import fails that were found in mempool as 'already there' (kallewoof) - - #11269 `61fb806` CTxMemPoolEntry::UpdateAncestorState: modifySiagOps param type (donaloconnor) - - #11747 `e970396` Fix: Open files read only if requested (Elbandi) - - #11737 `46d1ebf` Document partial validation in ConnectBlock() (sdaftuar) - - #10699 `c090262` Make all script validation flags backward compatible (sipa) - - #10279 `214046f` Add a CChainState class to validation.cpp to take another step towards clarifying internal interfaces (TheBlueMatt) - - #11824 `d9fdac1` Block ActivateBestChain to empty validationinterface queue (TheBlueMatt) - - #12127 `9501dc2` Remove unused mempool index (sdaftuar) - - #12118 `44080a9` Sort mempool by min(feerate, ancestor_feerate) (sdaftuar) - - #8498 `0e3a411` Minimize the number of times it is checked that no money... (jtimon) - - #12368 `3f5012b` Hold mempool.cs for the duration of ATMP (TheBlueMatt) - - #12401 `d44cd7e` Reset pblocktree before deleting LevelDB file (Sjors) - - #12415 `f893824` Interrupt loading thread after shutdown request (promag) ### P2P protocol and network code - - #10596 `6866b49` Add vConnect to CConnman::Options (benma) - - #10663 `9d31ed2` Split resolve out of connect (theuni) - - #11113 `fef65c4` Ignore getheaders requests for very old side blocks (jimpo) - - #11585 `5aeaa9c` addrman: Add missing lock in Clear() (CAddrMan) (practicalswift) - - #11524 `5ef3b69` De-duplicate connection eviction logic (tjps) - - #11580 `1f4375f` Do not send (potentially) invalid headers in response to getheaders (TheBlueMatt) - - #11655 `aca77a4` Assert state.m_chain_sync.m_work_header in ConsiderEviction (practicalswift) - - #11744 `3ff6ff5` Add missing locks in net.{cpp,h} (practicalswift) - - #11740 `59d3dc8` Implement BIP159 NODE_NETWORK_LIMITED (pruned peers) *signaling only* (jonasschnelli) - - #11583 `37ffa16` Do not make it trivial for inbound peers to generate log entries (TheBlueMatt) - - #11363 `ba2f195` Split socket create/connect (theuni) - - #11917 `bc66765` Add testnet DNS seed: seed.testnet.bitcoin.sprovoost.nl (Sjors) - - #11512 `6e89de5` Use GetDesireableServiceFlags in seeds, dnsseeds, fixing static seed adding (TheBlueMatt) - - #12262 `16bac24` Hardcoded seed update (laanwj) - - #12270 `9cf6393` Update chainTxData for 0.16 (laanwj) - - #12392 `0f61651` Fix ignoring tx data requests when fPauseSend is set on a peer (TheBlueMatt) ### Wallet - - #11039 `fc51565` Avoid second mapWallet lookup (promag) - - #10952 `2621673` Remove vchDefaultKey and have better first run detection (achow101) - - #11007 `fc5c237` Fix potential memory leak when loading a corrupted wallet file (practicalswift) - - #10976 `07c92b9` Move some static functions out of wallet.h/cpp (ryanofsky) - - #11117 `961901f` Prepare for non-Base58 addresses (sipa) - - #10916 `e6ab88a` add missing lock to crypter GetKeys() (benma) - - #10767 `791a0e6` Clarify wallet initialization / destruction interface (jnewbery) - - #11250 `c22a53c` Bump wallet version to 159900 and remove the `usehd` option (achow101) - - #11307 `4f7e37e` Display non-HD error on first run (MarcoFalke) - - #11408 `69c7ece` Fix parameter name typo in ErasePurpose walletdb method (PierreRochard) - - #11167 `aa624b6` Full BIP173 (Bech32) support (sipa) - - #11594 `0ecc630` Improve -disablewallet parameter interaction (promag) - - #10368 `77ba4bf` Remove helper conversion operator from wallet (kallewoof) - - #11074 `99ec126` Assert that CWallet::SyncMetaData finds oldest transaction (BitonicEelis) - - #11272 `e6e3fc3` CKeystore/CCrypter: move relevant implementation out of the header (jonasschnelli) - - #10286 `927a1d7` Call wallet notify callbacks in scheduler thread (without cs_main) (TheBlueMatt) - - #10600 `4ed8180` Make feebumper class stateless (ryanofsky) - - #11466 `d080a7d` Specify custom wallet directory with -walletdir param (MeshCollider) - - #11839 `8ab6c0b` Don't attempt mempool entry for wallet transactions on startup (instagibbs) - - #11854 `2214954` Split up key and script metadata for better type safety (ryanofsky) - - #11870 `ef8ba7d` Remove unnecessary mempool lock in ReacceptWalletTransactions (promag) - - #11864 `2ae58d5` Make CWallet::FundTransaction atomic (promag) - - #11886 `df71819` Clarify getbalance meaning a tiny bit in response to questions (TheBlueMatt) - - #11923 `81c89e9` Remove unused fNoncriticalErrors variable from CWalletDB::FindWalletTx (PierreRochard) - - #11726 `604e08c` Cleanups + nit fixes for walletdir PR (MeshCollider) - - #11403 `d889c03` Segwit wallet support (sipa) - - #11970 `b7450cd` Add test coverage for bitcoin-cli multiwallet calls (ryanofsky) - - #11904 `66e3af7` Add a lock to the wallet directory (MeshCollider) - - #12101 `c7978be` Clamp walletpassphrase timeout to 2^30 seconds and check its bounds (achow101) - - #12210 `17180fa` Deprecate addwitnessaddress (laanwj) - - #12220 `f4c942e` Error if relative -walletdir is specified (ryanofsky) - - #11281 `8470e64` Avoid permanent cs_main/cs_wallet lock during RescanFromTime (jonasschnelli) - - #12119 `9594139` Use P2WPKH change output if any destination is P2WPKH or P2WSH (Sjors) - - #12213 `eadb2da` Add address type option to addmultisigaddress (promag) - - #12276 `7936446` Remove duplicate mapWallet lookups (promag) ### RPC and other APIs - - #11008 `3841aaf` Enable disablesafemode by default (gmaxwell) - - #11050 `7ed57d3` Avoid treating null RPC arguments different from missing arguments (ryanofsky) - - #10997 `affe927` Add option -stdinrpcpass to bitcoin-cli to allow RPC password to be read from standard input (jharvell) - - #11179 `e0e3cbb` Push down safe mode checks (laanwj) - - #11203 `d745b4c` add wtxid to mempool entry output (sdaftuar) - - #11099 `bc561b4` Add savemempool RPC (greenaddress) - - #10838 `66a5b41` (finally) remove getinfo (TheBlueMatt) - - #10753 `7fcd61b` test: Check RPC argument mapping (laanwj) - - #11288 `0f8e095` More user-friendly error message when partially signing (MeshCollider) - - #11031 `ef8340d` deprecate estimatefee (jnewbery) - - #10858 `9a8e916` Add "errors" field to getblockchaininfo and unify "errors" field in get*info RPCs (achow101) - - #11021 `90926db` Fix getchaintxstats() (AkioNak) - - #11367 `3a93270` getblockchaininfo: Add disk_size, prune_target_size (esotericnonsense) - - #11006 `a1d78b5` Improve shutdown process (promag) - - #11529 `ff92fbf` Avoid slow transaction search with txindex enabled (promag) - - #11618 `87d90ef` Lock cs_main in blockToJSON/blockheaderToJSON (practicalswift) - - #11626 `998c304` Make `logging` RPC public (laanwj) - - #11258 `033c786` Add initialblockdownload to getblockchaininfo (jnewbery) - - #11087 `99bc0b4` Diagnose unsuitable outputs in lockunspent() (BitonicEelis) - - #11710 `9388639` cli: Reject arguments to -getinfo (laanwj) - - #11738 `d4267a3` Fix sendrawtransaction hang when sending a tx already in mempool (TheBlueMatt) - - #11753 `32c9b57` clarify abortrescan rpc use (instagibbs) - - #11191 `ef14f2e` Improve help text and behavior of RPC-logging (AkioNak) - - #10874 `9e38d35` getblockchaininfo: Loop through the bip9 soft fork deployments instead of hard coding (achow101) - - #10275 `497d0e0` Allow fetching tx directly from specified block in getrawtransaction (kallewoof) - - #11178 `fee0370` Add iswitness parameter to decode- and fundrawtransaction RPCs (MeshCollider) - - #11667 `711d16c` Add scripts to dumpwallet RPC (MeshCollider) - - #11475 `9bad8d6` mempoolinfo should take ::minRelayTxFee into account (mess110) - - #12001 `a9a49e6` Adding ::minRelayTxFee amount to getmempoolinfo and updating help (jeffrade) - - #12198 `adce1de` Add deprecation error for `getinfo` (laanwj) - - #11415 `69ec021` Disallow using addresses in createmultisig (achow101) - - #12278 `288deac` Add special error for genesis coinbase to getrawtransaction (MeshCollider) - - #11362 `c6223b3` Remove nBlockMaxSize from miner opt struct as it is no longer used (gmaxwell) - - #10825 `28485c7` Set regtest JSON-RPC port to 18443 to avoid conflict with testnet 18332 (fametrano) - - #11303 `e542728` Fix estimatesmartfee rounding display issue (TheBlueMatt) - - #7061 `8c2de82` Add RPC call "rescanblockchain " (jonasschnelli) - - #11055 `95e14dc` RPC getreceivedbyaddress should return error if called with address not owned by the wallet (jnewbery) - - #12366 `93de37a` http: Join worker threads before deleting work queue (laanwj) - - #12315 `758a41e` Bech32 addresses in dumpwallet (fivepiece) - - #12427 `3762ac1` Make signrawtransaction accept P2SH-P2WSH redeemscripts (sipa) ### GUI - - #10964 `64e66bb` Pass SendCoinsRecipient (208 bytes) by reference (practicalswift) - - #11169 `5b8af7b` Make tabs toolbar no longer have a context menu (achow101) - - #10911 `9c8f365` Fix typo and access key in optionsdialog.ui (keystrike) - - #10770 `ea729d5` Drop upgrade-cancel callback registration for a generic "cancelable" (TheBlueMatt) - - #11156 `a3624dd` Fix memory leaks in qt/guiutil.cpp (danra) - - #11268 `31e72b2` [macOS] remove Growl support, remove unused code (jonasschnelli) - - #11193 `c5c77bd` Terminate string *pszExePath after readlink and without using memset (practicalswift) - - #11508 `ffa5159` Fix crash via division by zero assertion (jonasschnelli) - - #11499 `6157e8c` Add upload and download info to the peerlist (debug menu) (aarongolliver) - - #11480 `ffc0b11` Add toggle for unblinding password fields (tjps) - - #11316 `22cdf93` Add use available balance in send coins dialog (CryptAxe, promag) - - #3716 `13e352d` Receive: Remove option to reuse a previous address (luke-jr) - - #11690 `f0c1f8a` Fix the StartupWMClass for bitoin-qt, so gnome-shell can recognize it (eklitzke) - - #10920 `f6f8d54` Fix potential memory leak in newPossibleKey(ChangeCWallet *wallet) (practicalswift) - - #11698 `7293d06` RPC-Console nested commands documentation (lmlsna) - - #11395 `38d31f9` Enable searching by transaction id (luke-jr) - - #11556 `91eeaa0` Improved copy for RBF checkbox and tooltip (Sjors) - - #11809 `80f9dad` Fix proxy setting options dialog crash (laanwj) - - #11616 `8585bb8` Update ban-state in case of dirty-state during periodic sweep (jonasschnelli) - - #11605 `f19ca12` Enable RBF by default in QT (Sjors) - - #12074 `a1136f0` Optimizes boolean expression model && model->haveWatchOnly() (251Labs) - - #12035 `eeb6d52` Change ?BTC to bits (jb55) - - #12092 `fd4ca17` Replaces numbered place marker %2 with %1 (251Labs) - - #12173 `bbc91b7` Use flexible font size for QRCode image address (jonasschnelli) - - #12211 `10d10d7` Avoid potential null dereference in ReceiveCoinsDialog constructor (ryanofsky) - - #12261 `f359afc` Bump BLOCK_CHAIN_SIZE to 200GB (laanwj) - - #11991 `062c8b6` Receive: checkbox for bech32 address (Sjors) - - #11644 `045a809` Fix qt build broken by 5a5e4e9 (TheBlueMatt) - - #11448 `d473e6d` reset addrProxy/addrSeparateProxyTor if colon char missing (mess110) - - #12377 `604f289` qt: Poll ShutdownTimer after init is done (MarcoFalke) - - #12374 `daaae36` qt: Make sure splash screen is freed on AppInitMain fail (laanwj) - - #12349 `ad10b90` shutdown: fix crash on shutdown with reindex-chainstate (theuni) ### Build system - - #10923 `2c9f5ec` travis: Build with --enable-werror under OS X (practicalswift) - - #11176 `df8c722` build: Rename --enable-experimental-asm to --enable-asm and enable by default (laanwj) - - #11286 `11dacc6` [depends] Don't build libevent sample code (fanquake) - - #7142 `801dd40` Travis: Test build against system libs (& Qt4) (luke-jr) - - #11380 `390771b` Remove outdated share/certs/ directory (MeshCollider) - - #11391 `7632310` Remove lxcbr0 lines from gitian-build.sh (MeshCollider) - - #11435 `167cef8` build: Make "make clean" remove all files created when running "make check" (practicalswift) - - #11460 `e022463` [depends] mac_alias 2.0.6, ds_store 1.1.2 (fanquake) - - #11541 `bb9ab0f` Build: Fix Automake warnings when running autogen.sh (fanquake) - - #11611 `0e70791` [build] Don't fail when passed --disable-lcov and lcov isn't available (fanquake) - - #11651 `3c098a8` refactor: Make all #includes relative to project root (laanwj, MeshCollider, ryanofsky) - - #11621 `1f7695b` [build] Add temp_bitcoin_locale_qrc to CLEAN_QT to fix make distcheck (fanquake) - - #11755 `84fa645` [Docs] Bump minimum required version of GCC to 4.8 (fanquake) - - #9254 `6d3dc52` [depends] ZeroMQ 4.2.2 (fanquake) - - #11842 `3c8f0a3` [build] Add missing stuff to clean-local (kallewoof) - - #11936 `483bb67` [build] Warn that only libconsensus can be built without Boost (fanquake) - - #11945 `7a11ba7` Improve BSD compatibility of contrib/install_db4.sh (laanwj) - - #11981 `180a255` Fix gitian build after libzmq bump (theuni) - - #11903 `8f68fd2` [trivial] Add required package dependencies for depends cross compilation (jonasschnelli) - - #12168 `45cf8a0` #include sys/fcntl.h to just fcntl.h (without sys/) (jsarenik) - - #12095 `3fa1ab4` Use BDB_LIBS/CFLAGS and pass --disable-replication (fanquake) - - #11711 `6378e5c` bitcoin_qt.m4: Minor fixes and clean-ups (fanquake) - - #11989 `90d4104` .gitignore: add QT Creator artifacts (Sjors) - - #11577 `c0ae864` Fix warnings (-Wsign-compare) when building with DEBUG_ADDRMAN (practicalswift) ### Tests and QA - - #11024 `3e55f13` Remove OldSetKeyFromPassphrase/OldEncrypt/OldDecrypt (practicalswift) - - #10679 `31b2612` Document the non-DER-conformance of one test in tx_valid.json (schildbach) - - #11160 `ede386c` Improve versionbits_computeblockversion test code consistency (danra) - - #10303 `f088a1b` Include ms/blk stats in Connect* benchmarks (kallewoof) - - #10777 `d81dccf` Avoid redundant assignments. Remove unused variables (practicalswift) - - #11260 `52f8877` travis: Assert default datadir isn't created, Run scripted diff only once (MarcoFalke) - - #11271 `638e6c5` travis: filter out pyenv (theuni) - - #11285 `3255d63` Add -usehd to excluded args in check-doc.py (MeshCollider) - - #11297 `16e4184` Make sure ~/.bitcoin doesn't exist before build (MeshCollider) - - #11311 `cce94c5` travis: Revert default datadir check (MarcoFalke) - - #11300 `f4ed44a` Add a lint check for trailing whitespace (MeshCollider) - - #11323 `4ce2f3d` mininode: add an optimistic write and disable nagle (theuni) - - #11370 `2d85899` Add getblockchaininfo functional test (promag) - - #11365 `f199b8a` Add Qt GUI tests to Overview and ReceiveCoin Page (anditto) - - #11293 `dbc4ae0` Deduplicate CMerkleBlock construction code, add test coverage (jamesob) - - #10440 `9e8ef9d` Add libFuzzer support (practicalswift) - - #10941 `364da2c` Add blocknotify and walletnotify functional tests (promag) - - #11420 `8928093` Bump univalue subtree and fix json formatting in tests (MarcoFalke) - - #10099 `424be03` Slightly Improve Unit Tests for Checkqueue (JeremyRubin) - - #11513 `14b860b` A few Python3 tidy ups (jnewbery) - - #11486 `2ca518d` Add uacomment tests (mess110) - - #11452 `02ac8c8` Improve ZMQ functional test (promag) - - #10409 `b5545d8` Add fuzz testing for BlockTransactions and BlockTransactionsRequest (practicalswift) - - #11389 `dd56166` Support having segwit always active in regtest (sipa, ajtowns, jnewbery) - - #11562 `5776582` bench: use std::chrono rather than gettimeofday (theuni) - - #11182 `f7388e9` Add P2P interface to TestNode (jnewbery) - - #11552 `b5f9f02` Improve wallet-accounts test (ryanofsky) - - #11638 `5e3f5e4` Dead mininode code (jnewbery) - - #11646 `fe503e1` Require a steady clock for bench with at least micro precision (TheBlueMatt) - - #11468 `76b3349` Make comp test framework more debuggable (jnewbery) - - #11623 `ee92243` Add missing locks to tests (practicalswift) - - #11035 `927e528` [contrib] Add Valgrind suppressions file (practicalswift) - - #11641 `7adeea3` Only allow disconnecting all NodeConns (MarcoFalke) - - #11677 `3bdf242` Remove unused NodeConn members (MarcoFalke) - - #11699 `66d46c7` [travis-ci] Only run linters on Pull Requests (jnewbery) - - #11654 `084f52f` Initialize recently introduced non-static class member lastCycles to zero in constructor (practicalswift) - - #11648 `ccc70a2` Add messages.py (jnewbery) - - #11713 `49667a7` Fix for mismatched extern definition in wallet tests (sipsorcery) - - #11707 `0d89fa0` Fix sendheaders (jnewbery) - - #11718 `9cdd2bc` Move pwalletMain to wallet test fixture (laanwj) - - #11714 `901ba3e` Test that mempool rejects coinbase transactions (jamesob) - - #11743 `3d6ad40` Add multiwallet prefix test (MarcoFalke) - - #11683 `a892218` Remove unused mininode functions {ser,deser}_int_vector(...). Remove unused imports (practicalswift) - - #11712 `9f2c2db` Split NodeConn from NodeConnCB (jnewbery) - - #11791 `13e31dd` Rename NodeConn and NodeConnCB (jnewbery) - - #11835 `f60b4ad` Add Travis check for unused Python imports (practicalswift) - - #11849 `ad1820c` Assert that only one NetworkThread exists (jnewbery) - - #11877 `d4991c0` Improve createrawtransaction functional tests (promag) - - #11220 `2971fd0` Check specific validation error in miner tests (Sjors) - - #11947 `797441e` Fix rawtransactions test (laanwj) - - #11946 `8049241` Remove unused variable (firstAddrnServices) (practicalswift) - - #11867 `18a1bba` Improve node network test (jnewbery) - - #11883 `cfd99dd` Add configuration file/argument testing (MeshCollider) - - #11879 `d4e404a` Remove redundant univalue_tests.cpp (jnewbery) - - #11748 `20166f8` Adding unit tests for GetDifficulty in blockchain.cpp (merehap) - - #11517 `5180a86` Improve benchmark precision (martinus) - - #11291 `a332a7d` Fix string concatenation to os.path.join and add exception case (dongsam) - - #11965 `d38d1a3` Note on test order in test_runner (MarcoFalke) - - #11997 `ddff344` util_tests.cpp: actually check ignored args (ajtowns) - - #12079 `45173fa` Improve prioritisetransaction test coverage (promag) - - #12150 `92a810d` Fix ListCoins test failure due to unset g_address_type, g_change_type (ryanofsky) - - #12133 `1d2eaba` Fix rare failure in p2p-segwit.py (sdaftuar) - - #12082 `0910cbe` Adding test case for SINGLE|ANYONECANPAY hash type in tx_valid.json (Christewart) - - #11796 `4db16ec` Functional test naming convention (ajtowns) - - #12227 `b987ca4` test_runner: Readable output if create_cache.py fails (ryanofsky) - - #12089 `126000b` Make TestNodeCLI command optional in send_cli (MarcoFalke) - - #11774 `6970b30` Rename functional tests (ajtowns) - - #12264 `598a9c4` Fix versionbits warning test (jnewbery) - - #12217 `1213be6` Add missing syncwithvalidationinterfacequeue to tests (MarcoFalke) - - #12292 `eebe458` Fix names of excluded extended tests for travis (ajtowns) - - #11789 `60d739e` [travis-ci] Combine logs on failure (jnewbery) - - #11838 `3e50024` Add getrawtransaction in_active_chain=False test (MarcoFalke) - - #12206 `898f560` Sync with validationinterface queue in sync_mempools (MarcoFalke) - - #12424 `ff44101` Fix rescan test failure due to unset g_address_type, g_change_type (ryanofsky) - - #12388 `e2431d1` travis: Full clone for git subtree check (MarcoFalke) ### Documentation - - #10680 `6366941` Fix inconsistencies and grammar in various files (MeshCollider) - - #11011 `7db65c3` Add a comment on the use of prevector in script (gmaxwell) - - #10878 `c58128f` Fix Markdown formatting issues in init.md (dongcarl) - - #11066 `9e00a62` Document the preference of nullptr over NULL or (void*)0 (practicalswift) - - #11094 `271e40a` Hash in ZMQ hash is raw bytes, not hex (runn1ng) - - #11026 `ea3ac59` Bugfix: Use testnet RequireStandard for -acceptnonstdtxn default (luke-jr) - - #11058 `4b65fa5` Comments: More comments on functions/globals in standard.h (jimpo) - - #11112 `3f726c9` [developer-notes] By default, declare single-argument constructors "explicit" (practicalswift) - - #11155 `a084767` Trivial: Documentation fixes for CVectorWriter ctors (danra) - - #11136 `108222b` Docs: Add python3 to list of dependencies on some platforms (danra) - - #11216 `81f8c03` Update hmac_sha256.h (utsavgupta) - - #11236 `ba05971` Add note on translations to CONTRIBUTING.md (MeshCollider) - - #11173 `4eb1f39` RPC: Fix currency unit string in the help text (AkioNak) - - #11135 `21e2f2f` Update developer notes with RPC response guidelines (promag) - - #11219 `bcc8a62` explain how to recompile a modified unit test (Sjors) - - #10779 `f656147` Create dependencies.md (flack) - - #10682 `2a56baf` Move the AreInputsStandard documentation next to its implementation (esneider) - - #11276 `ee50c9e` Update CONTRIBUTING.md to reduce unnecessary review workload (jonasschnelli) - - #11264 `b148803` Fix broken Markdown table in dependencies.md (practicalswift) - - #10691 `ce82985` Properly comment about shutdown process in init.cpp file (wraith7) - - #11330 `ae233c4` Fix comments for DEFAULT_WHITELIST[FORCE]RELAY (danra) - - #11340 `d6d2c85` Fix validation comments (danra) - - #11305 `2847480` Update release notes and manpages for 0.16 (MarcoFalke) - - #11132 `551d7bf` Document assumptions that are being made to avoid NULL pointer dereferences (practicalswift) - - #11390 `12ed800` Document scripted-diff (jnewbery) - - #11392 `a3b4c59` Fix stale link in gitian-building.md (shooterman) - - #11401 `4202273` Move gitian building to external repo (MarcoFalke) - - #11414 `bbc901d` Remove partial gitian build instructions from descriptors dir (fanquake) - - #11571 `c95832d` Fixed a couple small grammatical errors (BitsInMyBlood) - - #11624 `f9b74ef` Change formatting for sequence of steps (vivganes) - - #11597 `6f01dcf` Fix error messages in CFeeBumper (kallewoof) - - #11438 `7fbf3c6` Updated Windows build doc for WSL/Xenial workaround (sipsorcery) - - #11663 `41aa9c4` Add getreceivedbyaddress release notes (MarcoFalke) - - #11533 `cbb54e7` Update WSL installation notes for Fall Creators update (Thoragh) - - #11680 `4db82b7` Add instructions for lcov report generation (jamesob) - - #11686 `54aedc0` Make ISSUE_TEMPLATE a bit shorter, mention hardware tests (TheBlueMatt) - - #11704 `ea68190` Windows build doc update (sipsorcery) - - #11706 `5197100` Make default issue text all comments to make issues more readable (TheBlueMatt) - - #11140 `1429132` Improve #endif comments (danra) - - #11729 `7a43fbb` links to code style guides (Sjors) - - #11793 `8879d50` Bump OS X version to 10.13 (Varunram) - - #11783 `16fff80` Fix shutdown in case of errors during initialization (laanwj) - - #11804 `00d25e9` Fixed outdated link with archive.is (TimothyShimmin) - - #11960 `4307062` Fix link to installation script (laudaa) - - #12027 `63a4dc1` Remove boost --c++ flag from osx build instructions (fernandezpablo85) - - #12062 `5961b23` Increment MIT Licence copyright header year on files modified in 2017 (akx20000a) - - #12063 `36a5a44` Update license year range to 2018 (akx20000a) - - #12093 `5691028` Fix incorrect Markdown link (practicalswift) - - #12143 `b0d626d` Fix link for BIP159 pull request (azuchi) - - #12112 `3c62868` Remove the ending slashes from RPC URI format (jackycjh) - - #12166 `e839d65` Clarify -walletdir usage (jnewbery) - - #12241 `b030133` Fix incorrect link in /test/ README.md (fanquake) - - #12187 `b5e4b9b` Updating benchmarkmarking.md with an updated sample output (jeffrade) - - #12294 `7cf1aea` Create NetBSD build instructions and fix compilation (fanquake) - - #12251 `cc5870a` initwallet: Do not translate highly technical addresstype help (MarcoFalke) - - #11984 `efae366` Update OpenBSD build instructions for 6.2 (cont'd) (laanwj) - - #12293 `9d9c418` Mention that HD is enabled if hdmasterkeyid is present in getwalletinfo RPC help (fanquake) - - #12077 `c04cb48` Correct `sendmany` curl example (251Labs) - - #10677 `b3ecb7b` Document that addmultisigaddress is intended for non-watchonly addresses (instagibbs) - - #12177 `cad504b` Fix address_type help text of getnewaddress and getrawchangeaddress (mruddy) ### Refactoring - - #9964 `b6a4891` Add const to methods that do not modify the object for which it is called (practicalswift) - - #10965 `655970d` Replace deprecated throw() with noexcept specifier (C++11) (practicalswift) - - #10645 `c484ec6` Use nullptr (C++11) instead of zero (0) as the null pointer constant (practicalswift) - - #10901 `22e301a` Fix constness of ArgsManager methods (promag) - - #10969 `4afb5aa` Declare single-argument (non-converting) constructors "explicit" (practicalswift) - - #11071 `dbf6bd6` Use static_assert(?, ?) (C++11) instead of assert(?) where appropriate (practicalswift) - - #10809 `c559884` optim: mark a few classes final (theuni) - - #10843 `2ab7c63` Add attribute [[noreturn]] (C++11) to functions that will not return (practicalswift) - - #11151 `7fd49d0` Fix header guards using reserved identifiers (danra) - - #11138 `2982511` Compat: Simplify bswap_16 implementation (danra) - - #11161 `745bbdc` Remove redundant explicitly defined copy ctors (danra) - - #11144 `cee4fe1` Move local include to before system includes (danra) - - #10781 `60dd9cc` Python cleanups (practicalswift) - - #10701 `50fae68` Remove the virtual specifier for functions with the override specifier (practicalswift) - - #11164 `38a54a5` Fix boost headers included as user instead of system headers (danra) - - #11143 `3aa60b7` Fix include path for bitcoin-config.h (danra) - - #8330 `59e1789` Structure Packing Optimizations in C{,Mutable}Transaction (JeremyRubin) - - #10845 `39ae413` Remove unreachable code (practicalswift) - - #11238 `6acdb1f` Add assertions before potential null deferences (MeshCollider) - - #11259 `089b742` Remove duplicate destination decoding (promag) - - #11232 `2f0d3e6` Ensure that data types are consistent (jjz) - - #10793 `efb4383` Changing &var[0] to var.data() (MeshCollider) - - #11196 `e278f86` Switch memory_cleanse implementation to BoringSSL's to ensure memory clearing even with -lto (maaku) - - #10888 `9821274` range-based loops and const qualifications in net.cpp (benma) - - #11351 `6c4fecf` Refactor: Modernize disallowed copy constructors/assignment (danra) - - #11385 `94c9015` Remove some unused functions and methods (sipa) - - #11301 `8776787` add m_added_nodes to connman options (benma) - - #11432 `058c0f9` Remove unused fTry from push_lock (promag) - - #11107 `e93fff1` Fix races in AppInitMain and others with lock and atomic bools (MeshCollider) - - #9572 `17f2ace` Skip witness sighash cache for non-segwit transactions (jl2012) - - #10961 `da0478e` Improve readability of DecodeBase58Check(...) (practicalswift) - - #11133 `a865b38` Document assumptions that are being made to avoid division by zero (practicalswift) - - #11073 `3bb77eb` Remove dead store in ecdsa_signature_parse_der_lax (BitonicEelis) - - #10898 `470c730` Fix invalid checks (NULL checks after dereference, redundant checks, etc.) (practicalswift) - - #11495 `50d72b3` [trivial] Make namespace explicit for is_regular_file (jnewbery) - - #11511 `db2f83e` [Init] Remove redundant exit(EXIT_FAILURE) instances and replace with return false (donaloconnor) - - #10866 `ef8a634` Fix -Wthread-safety-analysis warnings. Compile with -Wthread-safety-analysis if available (practicalswift) - - #11221 `0dec4cc` Refactor: simpler read (gnuser) - - #10696 `ef3758d` Remove redundant nullptr checks before deallocation (practicalswift) - - #11043 `5e9be16` Use std::unique_ptr (C++11) where possible (practicalswift) - - #11353 `05a7619` Small refactor of CCoinsViewCache::BatchWrite() (danra) - - #10749 `2adbddb` Use compile-time constants instead of unnamed enumerations (remove "enum hack") (practicalswift) - - #11603 `a933cb1` Move RPC registration out of AppInitParameterInteraction (ryanofsky) - - #11722 `26efc22` Switched sync.{cpp,h} to std threading primitives (tjps) - - #10493 `fbce66a` Use range-based for loops (C++11) when looping over map elements (practicalswift) - - #11337 `0d7e0a3` Fix code constness in CBlockIndex::GetAncestor() overloads (danra) - - #11516 `0e722e8` crypto: Add test cases covering the relevant HMAC-SHA{256,512} key length boundaries (practicalswift) - - #10574 `5d132e8` Remove includes in .cpp files for things the corresponding .h file already included (practicalswift) - - #11884 `66479c0` Remove unused include in hash.cpp (kallewoof) - - #10839 `c66adb2` Don't use pass by reference to const for cheaply-copied types (bool, char, etc.) (practicalswift) - - #10657 `79399c8` Utils: Improvements to ECDSA key-handling code (str4d) - - #12250 `e37ca2b` Make CKey::Load references const (ryanofsky) - - #12108 `9220426` Remove unused fQuit var from checkqueue.h (donaloconnor) - - #12159 `f3c7062` Use the character based overload for std::string::find (kekimusmaximus) - - #12266 `3448907` Move scheduler/threadGroup into common-init instead of per-app (TheBlueMatt) ### Miscellaneous - - #11246 `777519b` github-merge: Coalesce git fetches (laanwj) - - #10871 `c9a4aa8` Handle getinfo in bitcoin-cli w/ -getinfo (revival of #8843) (achow101) - - #11419 `093074b` Utils: Fix launchctl not being able to stop bitcoind (OmeGak) - - #11394 `6e4e98e` Perform a weaker subtree check in Travis (sipa) - - #11702 `4122112` [build] Add a script for installing db4 (jamesob) - - #11794 `dd49862` Prefix leveldb debug logging (laanwj) - - #11781 `24df9af` Add `-debuglogfile` option (laanwj) - - #10773 `c17f11f` Shell script cleanups (practicalswift) - - #11829 `7630a1f` Test datadir specified in conf file exists (MeshCollider) - - #11836 `d44535d` Rename rpcuser.py to rpcauth.py (hkjn) - - #11831 `d48ab83` Always return true if AppInitMain got to the end (TheBlueMatt) - - #11943 `1808660` contrib: fix typo in install_db4.sh help message (laanwj) - - #12075 `c991b30` [scripts] Add missing univalue file to copyright_header.py (fanquake) - - #12197 `000ac4f` Log debug build status and warn when running benchmarks (laanwj) - - #10672 `6ab0e4c` Avoid division by zero in the case of a corrupt estimates file (practicalswift) - - #11273 `cdd6bbf` Ignore old format estimation file (Xekyo) - - #11951 `1fb34e0` Remove dead feeest-file read code for old versions (TheBlueMatt) - - #11421 `9ccafb1` Merge current secp256k1 subtree (MarcoFalke) - - #11573 `2631d55` [Util] Update tinyformat.h (fanquake) - - #10529 `331352f` Improve bitcoind systemd service file (Flowdalic) - - #11620 `70fec9e` [build] .gitignore: add background.tiff (Sjors) - - #11558 `68e021e` Minimal code changes to allow msvc compilation (sipsorcery) - - #11284 `10bee0d` Fix invalid memory access in CScript::operator+= (guidovranken, ajtowns) - - #10939 `a1f7f18` [init] Check non-emptiness of -blocknotify command prior to executing (practicalswift) - - #11467 `937613d` Fix typos. Use nullptr instead of NULL (practicalswift) - - #11834 `5bea05b` [verify-commits] Fix gpg.sh's echoing for commits with '\n' (TheBlueMatt) - - #11830 `a13e443` rpcuser.py: Use 'python' not 'python2' (hkjn) - - #12194 `7abb0f0` Add change type option to fundrawtransaction (promag) - - #12269 `2ae7cf8` Update defaultAssumeValid to block 506067 (gmaxwell) - - #11952 `9ab9963` univalue: Bump subtree (MarcoFalke) - - #12367 `09fc859` Fix two fast-shutdown bugs (TheBlueMatt) - - #12422 `4d54e7a` util: Make LockDirectory thread-safe, consistent, and fix OpenBSD 6.2 build (laanwj) Credits ======= Thanks to everyone who directly contributed to this release: - - 251 - - Aaron Clauson - - Aaron Golliver - - aaron-hanson - - Adam Langley - - Akio Nakamura - - Akira Takizawa - - Alejandro Avil?s - - Alex Morcos - - Alin Rus - - Anditto Heristyo - - Andras Elso - - Andreas Schildbach - - Andrew Chow - - Anthony Towns - - azuchi - - Carl Dong - - Chris Moore - - Chris Stewart - - Christian Gentry - - Cory Fields - - Cristian Mircea Messel - - CryptAxe - - Dan Raviv - - Daniel Edgecumbe - - danra - - david60 - - Donal O'Connor - - dongsamb - - Dusty Williams - - Eelis - - esneider - - Evan Klitzke - - fanquake - - Ferdinando M. Ametrano - - fivepiece - - flack - - Florian Schmaus - - gnuser - - Gregory Maxwell - - Gregory Sanders - - Henrik Jonsson - - Jack Grigg - - Jacky C - - James Evans - - James O'Beirne - - Jan Sarenik - - Jeff Rade - - Jeremiah Buddenhagen - - Jeremy Rubin - - Jim Posen - - jjz - - Joe Harvell - - Johannes Kanig - - John Newbery - - Johnson Lau - - Jonas Nick - - Jonas Schnelli - - Jo?o Barbosa - - Jorge Tim?n - - Karel B?lek - - Karl-Johan Alm - - klemens - - Kyuntae Ethan Kim - - laudaa - - Lawrence Nahum - - Lucas Betschart - - Luke Dashjr - - Luke Mlsna - - MarcoFalke - - Mark Friedenbach - - Marko Bencun - - Martin Ankerl - - Matt Corallo - - mruddy - - Murch - - NicolasDorier - - Pablo Fernandez - - Paul Berg - - Pedro Branco - - Pierre Rochard - - Pieter Wuille - - practicalswift - - Randolf Richardson - - Russell Yanofsky - - Samuel Dobson - - Sean Erle Johnson - - Shooter - - Sjors Provoost - - Suhas Daftuar - - Thomas Snider - - Thoragh - - Tim Shimmin - - Tomas van der Wansem - - Utsav Gupta - - Varunram Ganesh - - Vivek Ganesan - - Werner Lemberg - - William Casarin - - Willy Ko - - Wladimir J. van der Laan As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCgAGBQJak7zUAAoJEB5K7WKYbNJdBbgH/3eTGVHCXl+qRKDTz2w5avNJ oqjCuWZNUmMLeAKUDKy30kYe9ORwuCSkP9pPeqNcq9LsVkaIQ6oGqbNIkJBrDUaz 0jy69sVHoixm5B6gZzT2ScTLa2mnljuI6lWseXxsww0kMGwG1zIqahF4UEzhG3Gm wQxcjzwq+rG/Ph74D0usH0q61FnbtcAo6hJCbUiqVFxFeQDA88yYeQoCoTT9IaHZ m2HaDhVLtZUyRdUlYM0U8gPwYsXbQ3e714/xFT8QQQHTkaekwzHaoAAHYyBMzUe4 n5UyVAZ0u3dX2jhsQlSsPyXofI18Y1c9hTdj27D217FPMUJ3PR+MSqPys9d6JV4= =aeRF -----END PGP SIGNATURE----- From roconnor at blockstream.io Tue Feb 27 16:25:59 2018 From: roconnor at blockstream.io (Russell O'Connor) Date: Tue, 27 Feb 2018 11:25:59 -0500 Subject: [bitcoin-dev] Revisiting BIP 125 RBF policy. In-Reply-To: <20180212234225.GA9131@fedora-23-dvm> References: <20180212225828.GB8551@fedora-23-dvm> <20180212234225.GA9131@fedora-23-dvm> Message-ID: On Mon, Feb 12, 2018 at 6:42 PM, Peter Todd wrote: > > Ah ok, I misunderstood and didn't realise you were talking about the case > where > Alice re-spends her unconfirmed payment. Unfortunately I don't think that > case > is possible to solve without putting some kind of restriction on spending > unconfirmed outputs; with a restriction it's fairly simple to solve. When you say that you don't think it is possible to solve, do you mean that there is a specific problem with this proposal of replacing transactions when offered a new transaction whose fee rate exceeds the package fee rate of the original transaction (and ensuring that the fee increase covers the size of the transactions being ejected)? Is your concern only about the ability to computing and track the package fee rate for transactions within the mempool or is there some other issue you foresee? -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at dglab.com Wed Feb 28 03:47:29 2018 From: karl at dglab.com (=?UTF-8?B?44Ki44Or44Og44CA44Kr44O844Or44Oo44OP44Oz?=) Date: Wed, 28 Feb 2018 03:47:29 +0000 Subject: [bitcoin-dev] Simple lock/unlock mechanism Message-ID: With the recent trend of physically robbing people for bitcoin (or other cryptocurrencies), I thought it would be beneficial to introduce a standard for locking up a portion of your bitcoin in a simple 'gotta-wait-awhile' system. The idea is to simply create a transaction spending a set of UTXOs to a P2SH address with an OP_CSV attached to it, and then throw away the private keys. To spend the bitcoin, you would have to broadcast the transaction and wait the given amount of time, then use the new txout. There are several ways to shoot yourself in the foot trying to do this manually, but e.g. Bitcoin Core could handle this in a fairly straightforward manner by introducing two new commands, which I call freeze and unfreeze: bitcoin-cli freeze [amount OR array of txid+vout objects] [days, default 1] E.g. bitcoin-cli freeze 10 5 E.g. bitcoin-cli freeze ["abc123:1", "def346:0"] 3 The unfreeze command would by default list all freezes: bitcoin-cli unfreeze txid days status bcd123 5 frozen dca999 3 frozen including the txid would broadcast the unfreeze and status would become 'thawing' until the amount becomes available: bitcoin-cli unfreeze bcd123 bitcoin-cli unfreeze txid days status bcd123 5 thawing dca999 3 frozen The benefit of this is that it becomes physically impossible for you to spend the coins until you thaw them, and if this becomes standard enough, it should disincentivize potential robbers as it would be expected that you keep most of your assets locked up. They could of course hold you hostage until the period is over, which may be worse, but I think that kind of operation would be substantially more difficult than a simply rob-and-run. The drawback is that you have to broadcast a transaction in order to spend the content, and you cannot bump the fee so the transaction could get stuck in a high-fee situation. -Kalle. From karl at dglab.com Wed Feb 28 04:34:18 2018 From: karl at dglab.com (=?UTF-8?B?44Ki44Or44Og44CA44Kr44O844Or44Oo44OP44Oz?=) Date: Wed, 28 Feb 2018 04:34:18 +0000 Subject: [bitcoin-dev] Simple lock/unlock mechanism In-Reply-To: References: Message-ID: A few p.s.'es: 1. Graftroot probably breaks this (someone could just sign the time-locked output with a script that has no time-lock). 2. Address reuse of discarded privkeys would be a problem. A way to alleviate might be that freezing includes a send to a new address and the privkeys for that new one are discarded instead. One extra transaction, but reduces the risk of accidentally throwing away `donations4mybook` vanity keys. -Kalle. On Wed, Feb 28, 2018 at 3:47 AM, ?????????? wrote: > With the recent trend of physically robbing people for bitcoin (or > other cryptocurrencies), I thought it would be beneficial to introduce > a standard for locking up a portion of your bitcoin in a simple > 'gotta-wait-awhile' system. > > The idea is to simply create a transaction spending a set of UTXOs to > a P2SH address with an OP_CSV attached to it, and then throw away the > private keys. > > To spend the bitcoin, you would have to broadcast the transaction and > wait the given amount of time, then use the new txout. > > There are several ways to shoot yourself in the foot trying to do this > manually, but e.g. Bitcoin Core could handle this in a fairly > straightforward manner by introducing two new commands, which I call > freeze and unfreeze: > > bitcoin-cli freeze [amount OR array of txid+vout objects] [days, default 1] > > E.g. bitcoin-cli freeze 10 5 > E.g. bitcoin-cli freeze ["abc123:1", "def346:0"] 3 > > The unfreeze command would by default list all freezes: > > bitcoin-cli unfreeze > txid days status > bcd123 5 frozen > dca999 3 frozen > > including the txid would broadcast the unfreeze and status would > become 'thawing' until the amount becomes available: > > bitcoin-cli unfreeze bcd123 > > bitcoin-cli unfreeze > txid days status > bcd123 5 thawing > dca999 3 frozen > > The benefit of this is that it becomes physically impossible for you > to spend the coins until you thaw them, and if this becomes standard > enough, it should disincentivize potential robbers as it would be > expected that you keep most of your assets locked up. They could of > course hold you hostage until the period is over, which may be worse, > but I think that kind of operation would be substantially more > difficult than a simply rob-and-run. > > The drawback is that you have to broadcast a transaction in order to > spend the content, and you cannot bump the fee so the transaction > could get stuck in a high-fee situation. > > -Kalle. From aj at erisian.com.au Wed Feb 28 22:30:44 2018 From: aj at erisian.com.au (Anthony Towns) Date: Thu, 1 Mar 2018 08:30:44 +1000 Subject: [bitcoin-dev] Simple lock/unlock mechanism In-Reply-To: References: Message-ID: <20180228223044.GA31415@erisian.com.au> On Wed, Feb 28, 2018 at 04:34:18AM +0000, ??? ?????? via bitcoin-dev wrote: > 1. Graftroot probably breaks this (someone could just sign the > time-locked output with a script that has no time-lock). Making the graftroot key be a 2-of-2 muSig with an independent third party that commits to only signing CLTV scripts could avoid this. Making it 3-of-3 or 5-of-5 could be even better if you can find multiple independent services that will do it. Cheers, aj From adam.back at gmail.com Wed Feb 28 23:36:05 2018 From: adam.back at gmail.com (Adam Back) Date: Thu, 1 Mar 2018 00:36:05 +0100 Subject: [bitcoin-dev] Simple lock/unlock mechanism In-Reply-To: <20180228223044.GA31415@erisian.com.au> References: <20180228223044.GA31415@erisian.com.au> Message-ID: Coincidentally I had thought of something similar to what Kalle posted about a kind of software only time-lock vault, and described the idea to a few people off-list. Re. Root incompatibility, if the key is deleted (as it must be) then a delegated signature can not be made that bypasses the CSV timeout restriction, so Root should not be incompatible with this. I think it would be disadvantageous to mark keys as Rootable vs not in a sighash sense, because then that is another privacy/fungibility loss eroding the uniformity advantage of Root when the delegate is not used. One drawback is deleting keys may itself be a bit difficult to assure with HD wallet seeds setup-time backup model. As Anthony described I think, a simpler though less robust model would be to have a third party refuse to co-sign until a pre-arranged time, and this would have the advantage of not requiring two on-chain transactions. With bulletproofs and CT rangeproofs / general ECDL ZKPS there is the possibility to prove things about the private key, or hidden attributes of a public key in zero-knowledge. Kind of what we want is to place private key covenants, where we have to prove that they are met without disclosing them. For example there is a hidden CSV and it is met OR there is no hidden CSV so it is not applicable. Adam On 28 February 2018 at 23:30, Anthony Towns via bitcoin-dev wrote: > On Wed, Feb 28, 2018 at 04:34:18AM +0000, ??? ?????? via bitcoin-dev wrote: >> 1. Graftroot probably breaks this (someone could just sign the >> time-locked output with a script that has no time-lock). > > Making the graftroot key be a 2-of-2 muSig with an independent third party > that commits to only signing CLTV scripts could avoid this. Making it > 3-of-3 or 5-of-5 could be even better if you can find multiple independent > services that will do it. > > Cheers, > aj > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev