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: