Re: [bitcoin-dev] BIP CPRKV: Check private key verify

I just realize that if we have OP_CAT, OP_CHECKPRIVATEKEYVERIFY (aka OP_CHECKPRIVPUBPAIR) is not needed (and is probably better for privacy) Bob has the prikey-x for pubkey-x. Alice and Bob will agree to a random secret nonce, k. They calculate r, in the same way as signing a transaction.

[bitcoin-dev] BIP draft: Merkelized Abstract Syntax Tree

BIP draft: https://github.com/jl2012/bips/blob/mast/bip-mast.mediawiki Reference implementation: https://github.com/jl2012/bitcoin/commit/f335cab76eb95d4f7754a718df201216a49 75d8c This BIP defines a new witness program type that uses a Merkle tree to encode mutually exclusive branches in a

Re: [bitcoin-dev] BIP CPRKV: Check private key verify

Seems it could be done without any new opcode: Bob is trading b Bitcoins for a altcoins. 1. Bob Pays D Bitcoins to IF CLTV DROP CHECKSIG ELSE HASH160 EQUALVERIFY CHECKSIG ENDIF 2. Alice pays a altcoins to IF HASH160 EQUALVERIFY CHECKSIG ELSE HASH160

Re: [bitcoin-dev] A roadmap to a better header format and bigger block size

I am actually suggesting 1 hardfork, not 2. However, different rules are activated at different time to enhance safety and reduce disruption. The advantage is people are required to upgrade once, not twice. Any clients designed for stage 2 should also be ready for stage 3. -Original

Re: [bitcoin-dev] On Hardforks in the Context of SegWit

Thanks for this proposal. Just some quick response: 1. The segwit hardfork (BIP HF) could be deployed with BIP141 (segwit softfork). BIP141 doesn't need grace period. BIP HF will have around 1 year of grace period. 2. Threshold is 95%. Using 4 versoin bits: a) BIP 141; b) BIP HF; c) BIP 141 if

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

You are making a very naïve assumption that miners are just looking for profit for the next second. Instead, they would try to optimize their short term and long term ROI. It is also well known that some miners would mine at a loss, even not for ideological reasons, if they believe that their

Re: [bitcoin-dev] Hardfork bit BIP

From: Gavin Andresen [mailto:gavinandre...@gmail.com] Sent: Friday, 5 February, 2016 06:16 To: Gregory Maxwell Cc: jl2012 ; Bitcoin Dev Subject: Re: [bitcoin-dev] Hardfork bit BIP >It is always possible I'm being dense, but I

Re: [bitcoin-dev] Pre-BIP Growth Soft-hardfork

This looks very interesting. The first time implementing it might be more painful but that will make subsequent hardforks a lot easier. Do you think it's good to include the median timestamp of the past 11 blocks after the block height in coinbase? That would make it easier to use it as

Re: [bitcoin-dev] Segregated Witness BIPs

The SW payment address format BIP is completely rewritten to introduce 2 types of new addresses: https://github.com/bitcoin/bips/pull/267 jl2012 via bitcoin-dev 於 2015-12-24 09:22 寫到: The SW payment address format BIP draft is ready and is pending BIP number assignment: https://github.com

Re: [bitcoin-dev] Segregated Witness BIPs

The SW payment address format BIP draft is ready and is pending BIP number assignment: https://github.com/bitcoin/bips/pull/267 This is the 3rd BIP for segwit. The 2nd one for Peer Services is being prepared by Eric Lombrozo Eric Lombrozo via bitcoin-dev 於 2015-12-23 10:22 寫到: I've been

[bitcoin-dev] A new payment address format for segregated witness or not?

On the -dev IRC I asked the same question and people seem don't like it. I would like to further elaborate this topic and would like to consult merchants, exchanges, wallet devs, and users for their preference Background: People will be able to use segregated witness in 2 forms. They either

Re: [bitcoin-dev] On the security of softforks

Rusty Russell via bitcoin-dev 於 2015-12-19 23:14 寫到: Jonathan Toomim via bitcoin-dev writes: On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev wrote: 1) The risk of an old full node wallet accepting a

[bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

I have done some calculation for the effect of a SW softfork on the actual total block size. Definitions: Core block size (CBS): The block size as seen by a non-upgrading full node Witness size (WS): The total size of witness in a block Total block size (TBS): CBS + WS Witness discount (WD):

Re: [bitcoin-dev] We need to fix the block withholding attack

After the meeting I find a softfork solution. It is very inefficient and I am leaving it here just for record. 1. In the first output of the second transaction of a block, mining pool will commit a random nonce with an OP_RETURN. 2. Mine as normal. When a block is found, the hash is

Re: [bitcoin-dev] We need to fix the block withholding attack

Chris Priest via bitcoin-dev 於 2015-12-19 22:34 寫到: Block witholding attacks are only possible if you have a majority of hashpower. If you only have 20% hashpower, you can't do this attack. Currently, this attack is only a theoretical attack, as the ones with all the hashpower today are not

Re: [bitcoin-dev] We need to fix the block withholding attack

Chris Priest 於 2015-12-19 22:47 寫到: On 12/19/15, jl2012 wrote: Chris Priest via bitcoin-dev 於 2015-12-19 22:34 寫到: Block witholding attacks are only possible if you have a majority of hashpower. If you only have 20% hashpower, you can't do this attack. Currently, this attack is

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

This is not correct. As only about 1/3 of nodes support BIP65 now, would you consider CLTV tx are less secure than others? I don't think so. Since one invalid CLTV tx will make the whole block invalid. Having more nodes to fully validate non-CLTV txs won't make them any safer. The same logic

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

I know my reply is a long one but please read before you hit send. I have 2 proposals: fast BIP102 + slow SWSF and fast SWSF only. I guess no one here is arguing for not doing segwit; and it is on the top of my wish list. My main argument (maybe also Jeff's) is that segwit is too complicated

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

I would also like to summarize my observation and thoughts after the Hong Kong workshop. 1. I'm so glad that I had this opportunity to meet so many smart developers who are dedicated to make Bitcoin better. Regular conference like this is very important for a young project, and it is

Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin

There are at least 2 proposals on the table: 1. SWSF (segwit soft fork) with 1MB virtual block limit, approximately equals to 2MB actual limit 2. BIP102: 2MB actual limit Since the actual limits for both proposals are approximately the same, it is not a determining factor in this discussion

Re: [bitcoin-dev] Segregated Witness features wish list

dGSaH0gqnb+WEkO5v5vBO4L6Cikc+lcp7zXqQzWpW uqm3QSrbKcbR6JEwDFoGQpDkcqpwpTIrOAk4B1jJRg== =J2KF -END PGP SIGNATURE- Gregory Maxwell 於 2015-12-10 04:51 寫到: On Thu, Dec 10, 2015 at 6:47 AM, jl2012--- via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: 4. Sum of fee, sigopcount,

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Dec 14, 2015 at 12:14 AM, Danny Thorpe wrote: What is the current behavior / cost that this proposal is trying to avoid? Are ancient utxos required to be kept in memory always in a fully validating node, or can

Re: [bitcoin-dev] Segregated Witness features wish list

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pieter Wuille 2015-12-13 13:07 : The use of a NOP opcode to indicate a witness script was something I considered at first too, but it's not really needed. You wouldn't be able to use that opcode in any place a normal opcode could occur, as it

[bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

It is a common practice in commercial banks that a dormant account might be confiscated. Confiscating or deleting dormant UTXOs might be too controversial, but allowing the UTXOs set growing without any limit might not be a sustainable option. People lose their private keys. People do stupid

[bitcoin-dev] Impacts of Segregated Witness softfork

Although the plan is to implement SW with softfork, I think many important (but non-consensus critical) components of the network would be broken and many things have to be redefined. 1. Definition of "Transaction ID". Currently, "Transaction ID" is simply a hash of a tx. With SW, we may need

[bitcoin-dev] Segregated Witness features wish list

It seems the current consensus is to implement Segregated Witness. SW opens many new possibilities but we need a balance between new features and deployment time frame. I'm listing by my priority: 1-2 are about scalability and have highest priority 1. Witness size limit: with SW we should

Re: [bitcoin-dev] Dealing with OP_IF and OP_NOTIF malleability

I assume this proposal is implemented at the same time as BIP62. As long as OP_IF/OP_NOTIF interprets the argument as a number, zero-padded number and negative zero are already prohibited in BIP62 Tier Nolan via bitcoin-dev 於 2015-11-06 04:37 寫到: I meant not to use the OP_PUSH opcodes to do

Re: [bitcoin-dev] Compatibility requirements for hard or soft forks

My answer is simply "No", you don't have to maintain backward compatibility for non-standard tx. The same question applies to P2SH. Before the deployment of BIP16, one could have created a time-locked tx with one of the output was in the form of HASH160 EQUAL. The , however, is not a hash of

Re: [bitcoin-dev] BIP 113: Median time-past is a HARDfork, not a softfork!

Currently, a tx maybe included in a block only if its locktime (x) is smaller than the timestamp of a block (y) BIP113 says that a tx maybe included in a block only if x is smaller than the median-time-past (z) It is already a consensus rule that y > z. Therefore, if x < z, x < y The new

Re: [bitcoin-dev] Why not checkpointing the transactions?

You are mixing multiple issues. 1. It is not possible to "checkpoint" in a totally decentralized and trustless way. You need the whole blockchain to confirm its validity, as a single invalid tx in the history will invalidate ALL blocks after it, even if the invalid tx is irrelevant to you.

Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change

BIP68 allows per-input locktime, though I don't know how this could be useful. BIP68 and BIP112 are mostly ready. If we try to reimplement relative-locktime without using nSequence, we may need to wait for another year for deployment. A compromise is to make BIP68 optional, indicated by a

Re: [bitcoin-dev] Crossing the line? [Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!]

According to the Oxford Dictionary, "coin" as a verb means "invent (a new word or phrase)". Undoubtedly you created the first functional SPV client but please retract the claim "I coined the term SPV" or that's plagiarism. And I'd like to highlight the following excerpt from the whitepaper:

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Jonathan Toomim (Toomim Bros) via bitcoin-dev 於 2015-09-29 09:30 寫到: SPV clients will appear to behave normally, and will continue to show new transactions and get confirmations in a timely fashion. However, they will be systematically susceptible to attack from double-spends that attempt to

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

Mike Hearn via bitcoin-dev 於 2015-09-28 11:38 寫到: My point about IsStandard is that miners can and do bypass it, without expecting that to carry financial consequences or lower the security of other users. By making it so a block which includes non-standard transactions can end up being seen as

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

+1 for deploying BIP65 immediately without further waiting. Agree with all Peter's points. If BIP65 has to follow the 0.12 schedule, it will take almost 9 months from now to complete the softfork. I don't see any good reason to wait for that long. We have too much talk, too little action.

Re: [bitcoin-dev] Weekly development meetings on IRC: schedule

There could not be a worse timing than this for those in China (3-4am), Japan/Korea (4-5am), and Australia (3-6am depends on which part of the country). Maybe we have no dev in this part of the planet? Is there any chance to review the timing in a weekly or monthly basis (also with a doodle

[bitcoin-dev] Fill-or-kill transaction

Fill-or-kill tx is not a new idea and is discussed in the Scaling Bitcoin workshop. In Satoshi's implementation of nLockTime, a huge range of timestamp (from 1970 to 2009) is wasted. By exploiting this unused range and with compromise in the time resolution, a fill-or-kill system could be

[bitcoin-dev] MAST with OP_EVAL and OP_CAT

Inspired by Pieter's Tree Signatures, I believe Merkleized Abstract Syntax Trees (MAST) could be implemented with only OP_CAT and OP_EVAL (BIP12). The idea is very simple. Using a similar example in Pieter's paper, scriptSig = Z1 0 1 1 X6 1 K9 0 scriptPubKey = DUP HASH160 EQUALVERIFY

Re: [bitcoin-dev] BIP 100 specification

V1234567/, /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5MB, the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/" Tier Nolan via bitcoin-dev 於 2015-09-03 07:59 寫到: On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>

Re: [bitcoin-dev] block size - pay with difficulty

Jeff Garzik via bitcoin-dev 於 2015-09-03 00:05 寫到: Schemes proposing to pay with difficulty / hashpower to change block size should be avoided. The miners incentive has always been fairly straightforward - it is rational to deploy new hashpower as soon as you can get it online. Introducing the

Re: [bitcoin-dev] Short review of previously-proposed exotic SIGHASH types

Bryan Bishop via bitcoin-dev 於 2015-08-30 14:56 寫到: SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY SIGHASH_WITHOUT_PREV_VALUE SIGHASH_WITHOUT_INPUT_TXID SIGHASH_WITHOUT_INPUT_INDEX SIGHASH_WITHOUT_INPUT_SEQUENCE SIGHASH_WITHOUT_OUTPUT_SCRIPTPUBKEY SIGHASH_WITHOUT_OUTPUT_VALUE SIGHASH_WITHOUT_INPUTS

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

Jorge Timón 於 2015-08-30 14:56 寫到: On Sun, Aug 30, 2015 at 7:13 PM, wrote: This is based on the assumption that miners would always like to use up the last byte of the available block size. However, this is just not true: 1. The 6 year blockchain history has shown that most

Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations

I have an ugly solution to this problem, with minimal change to the current softfork logic, and still allows all features described in sipa's Version bits BIP 1. xVersion = nVersion AND 0b10011000 2. miners supporting BIP65 will set xVersion = 8 or greater 3. If 750 of

Re: [bitcoin-dev] Questiosn about BIP100

Mode could be ruled out immediately. Just consider this: 34% 8MB, 33% 1.5MB, 33% 1.2MB I personally believe the median is the most natural and logical choice. 51% of miners can always force the 49% to follow the simple majority choice through a 51% attack. Using median will eliminate the

Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin

Very good, I can't wait to see it. Please code it up and submit a pull request to github. Don't expect someone will do it for you. prabhat via bitcoin-dev 於 2015-08-27 08:06 寫到: snip. Folks, suggest something, scrap my idea, but let's build something to save this ecosystem, otherwise it

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Your proposal also permanently burns a sequence bit. It depends on how we value a nSequence bit and a nVersion bit. I think there is a trade-off here: 1. nSequence is signed by each TxIn individually, while all TxIns must share the same nVersion 2. If nVersion is used to indicate the

[bitcoin-dev] Encouraging mining of the first few big blocks with OP_CSV and BIP68

Someone is going to burn 150BTC to create a backlog of 30-day in September. https://www.reddit.com/r/Bitcoin/comments/3hgke4/coinwallet_says_bitcoin_stress_test_in_september/ However, the money could be spent more wisely by encouraging mining of the first few big blocks Assumptions: 1.

Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime

Gregory Maxwell via bitcoin-dev 於 2015-08-23 21:01 寫到: Seperately, to Mark and Btcdrank: Adding an extra wrinkel to the discussion has any thought been given to represent one block with more than one increment? This would leave additional space for future signaling, or allow, for example,

Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners

Peter Todd via bitcoin-dev 於 2015-08-19 01:50 寫到: 2) nVersion mask, with IsSuperMajority() In this option the nVersion bits set by XT/Not-Bitcoin-XT miners would be masked away, prior to applying standard IsSuperMajority() logic: block.nVersion ~0x2007 This means that

Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

odinn via bitcoin-dev 於 2015-08-19 07:25 寫到: The big problem is BIP101 being deployed as a Schism hardfork. This is certainly a problem. No, BitcoinXT won't become a Schism hardfork, or may be just for a few days, at most. There is one, and only one scenario that BitcoinXT will win:

[bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?

As I understand, there is already a consensus among core dev that block size should/could be raised. The remaining questions are how, when, how much, and how fast. These are the questions for the coming Bitcoin Scalability Workshops but immediate consensus in these issues are not guaranteed.

Re: [bitcoin-dev] Miners are struggling with blocks far smaller than 750KB blocks and resorting to SPV mining

The traffic between the pool server and individual hashers is far busier than 50kB/30s. If their bandwidth is so limited, hashers would have switched to other pools already. All these data may prove is they have very bad mining codes. For example, their hashers may not be required to update

Re: [bitcoin-dev] Annoucing Not-BitcoinXT

Thanks to mining centralization, such attempts won't be successful. Asking mining pools to mine spoofing blocks in their real name is even harder than asking them to run the real BitcoinXT Node count is always manipulable, there is nothing new. People running this will only be interpreted as

Re: [bitcoin-dev] The use of tx version field in BIP62 and 68

of these new consensus rules you want to apply your transaction. On Aug 8, 2015 11:51 AM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: BIP68 rules and some of the BIP62 rules are applied only if the tx version is =2 and =3 respectively. Therefore, it is not possible

Re: [bitcoin-dev] Fees and the block-finding process

Pieter Wuille via bitcoin-dev 於 2015-08-07 12:28 寫到: On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille pieter.wui...@gmail.com wrote: I guess my question (and perhaps that's what Jorge is after): do you feel that

Re: [bitcoin-dev] Block size implementation using Game Theory

It won't work as you thought. If a miner has 95% of hashing power, he would have 95% of chance to find the next block and collect the penalty. In long term, he only needs to pay 5% penalty. It's clearly biased against small miners. Instead, you should require the miners to burn the penalty.

[bitcoin-dev] Wrapping up the block size debate with voting

As now we have some concrete proposals (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html), I think we should wrap up the endless debate with voting by different stakeholder groups. - Candidate proposals Candidate proposals must be

Re: [bitcoin-dev] Wrapping up the block size debate with voting

system, not a democracy. Find a solution that everyone agrees on, or don't. On Aug 4, 2015 9:51 AM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: As now we have some concrete proposals (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html [1]), I think

Re: [bitcoin-dev] Wrapping up the block size debate with voting

, and these scenarios have implications for usage, scale, degree of decentralization and security. CS is science, there is no reason for this generation not to apply rigorous Computer Science to Bitcoin. Venzen On 08/04/2015 02:50 PM, jl2012 via bitcoin-dev wrote: As now we have some concrete

Re: [bitcoin-dev] BIP draft: Hardfork bit

I have put it on the github: https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki I removed the specification of coinbase message to make it simpler. Instead, it requires that a flag block must not be shared by multiple hardfork proposals. I'm not sure whether it is a Standard,

Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal

Yes, data-center operators are bound to follow laws, including NSLs and gag orders. How about your ISP? Is it bound to follow laws, including NSLs and gag orders? https://edri.org/irish_isp_introduces_blocking/ Do you think everyone should run a full node behind TOR? No way, your

[bitcoin-dev] A compromise between BIP101 and Pieter's proposal

There is a summary of the proposals in my previous mail at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html I think there could be a compromise between Gavin's BIP101 and Pieter's proposal (called BIP103 here). Below I'm trying to play with the parameters,

Re: [bitcoin-dev] CORRECTIONS: A summary of block size hardfork proposals

I am making some corrections to my previous summary Currently, there are 4 block size BIP by Bitcoin developers: BIP100 by Jeff: http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf BIP101 by Gavin: https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki BIP102 by Jeff:

Re: [bitcoin-dev] BIP draft: Hardfork bit

Quoting Tier Nolan via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org: On Thu, Jul 23, 2015 at 5:23 PM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: 2) Full nodes and SPV nodes following original consensus rules may not be aware of the deployment of a hardfork