Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin
On 08/27/2015 09:39 AM, prabhat via bitcoin-dev wrote: Fine point. So where is the solution? What to do? How about nothing. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin
Fine point. So where is the solution? What to do? Prabhat Kumar Singh Prabhat Kumar Singh On Thu, Aug 27, 2015 at 6:58 PM, Gavin Andresen gavinandre...@gmail.com wrote: Have you talked with anybody at the Bitcoin Foundation about this proposal? As Chief Scientist of the Foundation, I am strongly opposed to any proposal that puts the Foundation in a position of centralized authority, so this is unacceptable: The Bitcoin Foundation will act as fair play party and enforcement body to control the misuse of vast financial powers which bitcoin has. The idea that a central organization can be trusted to keep secrets secure is just fundamentally wrong. In the very recent past we have seen government organizations fail in that task (the NSA, the OPM) and we see commercial organizations that SHOULD be highly motivated to do a good job also fail (e.g. the Ashley Madison leak). Even if it were technically possible, I would be opposed because decentralization is a bedrock principle of Bitcoin. -- -- Gavin Andresen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin
So where is the solution? What to do? AML-KYC is mostly something that sits on top of the Bitcoin protocol. Take Coinase, inc. as an example. They check bank accounts before they open your account and they link your Bitcoin address to your account in their database. Then they ask for an explanation of why you are using the account. Then they track your coins to a certain extent once you actually buy Bitcoins. None of these activities are directly involving the protocol or would require changes to the Bitcoin system. What you can do is develop standards for using Bitcoin and entities that need to follow AML-KYC can choose to follow those standards if they want when they conduct business using Bitcoin. You can add a small amount of extraneous data to transactions that could show you followed some AML-KYC procedure. If you did that you could have a white list of complaint transactions rather than a black list of non-compliant transactions as you seem to be proposing. I am not sure how you would actually do something like that or how it would work but it is an interesting concept (not necessarily good, but interesting). Russ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin
So you mean that, 1. Govt agencies already know about everything and anything this subject is about, but passively. 2. Due to passive nature, the actions are post incident and not pre. So there is a risk of many ticking time-bombs which some JB (Jack Bauer or James Bond or Jai Singh Rathore) would diffuse. Sorry for being dramatic, the purpose is to make the point, and nothing else. 3. The subjected proposal doesn't breach the decentralisation, but just not like swiss democracy. I am not a legal expert, but know this much that there are 2 kinds of crimes, one against liberty and other against life. Most of online privacy advocacy is for liberty. But money is attached to life and not liberty. So this has to change. It means life for many and many depend on it. And the appeal is, Let us get active. PS: I do not own much of bitcoins to be an advocate, but many others do and any mayhem would affect me somehow, even if in farthest of world. Best, Prabhat Kumar Singh On Thu, Aug 27, 2015 at 7:18 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Thu, Aug 27, 2015 at 9:39 AM, prabhat prabha...@gmail.com wrote: So where is the solution? What to do? This is a development list; organizations like https://coincenter.org/ work on high-level policy issues. Last I heard, competent law enforcement organizations said they were perfectly capable of tracking down criminals using Bitcoin using traditional investigative techniques (like infiltrating criminal organizations or setting up honeypots). Given how many dark markets have either disappeared or been taken down, it seems they are correct. -- -- Gavin Andresen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]
Proposal 1 does not deal with Tx fee. Proposal 2 does. According to proposal 2, miners wont be able to increase or decrease Max Block Size only by manipulating Tx fee. They have to manipulate... i. Tx fee of ~4000 blocks. ii. Block size of ~4000 blocks. I never proposed *next block collects Tx fee from previous block*. Not sure what you mean here! On Tue, Aug 25, 2015 at 2:49 PM, Chun Wang 1240...@gmail.com wrote: Proposal 1 looks good, but tx fee collected can be manipulated by miners. I like the idea next block collect the tx fee from previous block. On Tue, Aug 25, 2015 at 5:07 PM, Upal Chakraborty via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Github: https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki pre BIP: 1xx Title: Dynamically Controlled Bitcoin Block Size Max Cap Author: Upal Chakraborty bitc...@upalc.com Status: Draft Type: Standards Track Created: 2015-08-24 /pre ==Abstract== This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... i. Depending only on previous block size calculation. ii. Depending on previous block size calculation and previous Tx fee collected by miners. ==Motivation== With increased adoption, transaction volume on bitcoin network is bound to grow. If the one megabyte max cap is not changed to a flexible one which changes itself with changing network demand, then adoption will hamper and bitcoin's growth may choke up. Following graph shows the change in average block size since inception... https://blockchain.info/charts/avg-block-size?timespan=allshowDataPoints=falsedaysAverageString=1show_header=truescale=0address= ==Specification== ===Proposal 1 : Depending only on previous block size calculation=== If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize Double MaxBlockSize Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize Half MaxBlockSize Else Keep the same MaxBlockSize ===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty) If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty TotalBlockSizeInLastButOneDifficulty) ) MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty TotalBlockSizeInLastButOneDifficulty) ) MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty Else Keep the same MaxBlockSize ==Rationale== These two proposals have been derived after discussion on [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and [ http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html bitcoin-dev mailing list]. The original idea and its evolution in the light of various arguements can be found [http://upalc.com/maxblocksize.php here]. ===Proposal 1 : Depending only on previous block size calculation=== This solution is derived directly from the indication of the problem. If transaction volume increases, then we will naturally see bigger blocks. On the contrary, if there are not enough transaction volume, but maximum block size is high, then only few blocks may sweep the mempool. Hence, if block size is itself taken into consideration, then maximum block size can most rationally be derived. Moreover, this solution not only increases, but also decreases the maximum block size, just like difficulty. ===Proposal 2 : Depending on previous block size calculation and previous Tx fee collected by miners=== This solution takes care of stable mining subsidy. It will not increase maximum
Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin
Guys, I strongly think the original prabhat e-mail is a parody. And I find very funny that important people have responded. But maybe I'm wrong! *:)* El jue., 27 ago. 2015 a las 11:04, Chris Pacia via bitcoin-dev ( bitcoin-dev@lists.linuxfoundation.org) escribió: On 08/27/2015 09:39 AM, prabhat via bitcoin-dev wrote: Fine point. So where is the solution? What to do? How about nothing. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Questiosn about BIP100
I have been reading the pdf and one thing I can't figure out is what you mean by most common floor. Is that the smallest block size that has a vote or the block size with the most votes or something else? On Mon, Aug 24, 2015 at 10:40 AM Jeff Garzik jgar...@gmail.com wrote: Great questions. - Currently working on technical BIP draft and implementation, hopefully for ScalingBitcoin.org. Only the PDF is publicly available as of today. - Yes, the initial deployment is in the same manner as size votes. On Fri, Aug 21, 2015 at 7:38 PM, Andrew C via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hi all, Is there any client or code that currently implements BIP 100? And how will it be deployed? WIll the initial fork be deployed in the same manner that the max block size changes are deployed described in the bip? Thanks ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin
But money is attached to life and not liberty I can't truly express in this email exactly how much I personally disagree with that statement/belief because I don't think the dev mailing list is the appropriate forum for such philosophical discussions. I will say this, though: I think you've missed much of the point of Bitcoin -- which monetary or economic liberty might perfectly describe -- and, I sincerely hope that proposals such as yours never gain ANY traction in this community. As far as I'm concerned, your ideas are the antithesis of this entire experiment. I'd be glad to have this discussion over a beer and hookah any time, but I won't take up any more space or time with it here. Oliver PS: sorry everyone! I just couldn't let this one go without comment... I'll go back to my usual lurking and learning now. :) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin
Prabhat, You write about OFAC, KYC, and AML. The *Office of Foreign Assets Control* (*OFAC*) is a financial intelligence https://en.wikipedia.org/wiki/Financial_intelligence and enforcement agency of the U.S. government charged with planning and execution of economic and trade sanctions https://en.wikipedia.org/wiki/Economic_sanctions in support of U.S. national security https://en.wikipedia.org/wiki/National_Security_of_the_United_States and foreign policy https://en.wikipedia.org/wiki/Foreign_policy_of_the_United_States objectives. KYC means Know Your Customer which is something every intelligent businessman does when his deals are significant. Support for KYC is built into reality and needs no qualification, compliance, or control. AML means Anti-Money-Laundering which smacks of overreach. Laundering money serves to hide behaviors that authorities dislike, many of which are actually helping the world. Neomoney says it best http://neomoney.net/?p=426: Indeed, money laundering describes a wide range of activities that are undertaken by innocent participants in the economy. Authorities’ growing expectation of a right to violate our privacy to enforce their laws, and an expectation that we do nothing to protect ourselves from that violation of privacy, lie at the heart of money laundering propaganda. So your work comes across as that of someone who has been duped into doing the bidding of the largest and most successful criminal organization on Earth. I do not accuse you of being deceived because no one can be blamed for the damage done to them by such a powerful parasite. I wish only to open your eyes, or, at least what worked for me, your ears http://peacerevolution.podomatic.com/. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin
I Truly respect your opinions. Prabhat Kumar Singh On Fri, Aug 28, 2015 at 12:25 AM, Oliver Petruzel opetru...@gmail.com wrote: But money is attached to life and not liberty I can't truly express in this email exactly how much I personally disagree with that statement/belief because I don't think the dev mailing list is the appropriate forum for such philosophical discussions. I will say this, though: I think you've missed much of the point of Bitcoin -- which monetary or economic liberty might perfectly describe -- and, I sincerely hope that proposals such as yours never gain ANY traction in this community. As far as I'm concerned, your ideas are the antithesis of this entire experiment. I'd be glad to have this discussion over a beer and hookah any time, but I won't take up any more space or time with it here. Oliver PS: sorry everyone! I just couldn't let this one go without comment... I'll go back to my usual lurking and learning now. :) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations
This BIP was assigned number 113. I have updated the text accordingly and added credits to Gregory Maxwell. Please see the changes in the pull request: https://github.com/bitcoin/bips/pull/182 On Sat, Aug 22, 2015 at 1:57 AM, Peter Todd via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: On Fri, Aug 21, 2015 at 12:13:09PM +0100, Thomas Kerin wrote: I submitted the pull-request for the median-past timelock BIP just now https://github.com/bitcoin/bips/pull/182 Any luck finding the link to this discussion? It would be nice to include this for posterity. Found it! From #bitcoin-wizards, 2013-07-16: 23:57 petertodd See, it'd be possible for nLockTime w/ time-based locks to create some really ugly incentives for miners to mine blocks at thelimit of the 2hr window - a timestamping chain could provide a way for nodes to at least detect that their clocks are off, especially given how peers can mess with them. 23:58 petertodd It's still dodgy though... I was thinking if nLockTime-by-time inclusion was based on the previous block timestamp it'd be ok, but that still leaves large miners with incentives to screw with the 2hr window, never mind how it can reduce competition if there exists clock skew in the mining nodes. --- Log closed Wed Jul 17 00:00:57 2013 --- Log opened Wed Jul 17 00:00:57 2013 00:01 petertodd (remember that if this is a timestamping facility any node wanting to know the current time simply gets a nonce timestamped, and then they know what time it is!) 00:11 Luke-Jr I don't see how nLockTime can discourage forward-dating blocks 00:11 Luke-Jr and there is no 2hr window backward.. 00:12 Luke-Jr well, I guess if miners are behaving there is . 00:19 petertodd The problem is a block being created with nTime actual time, and the incentive is to get a head start on other miners to put, say, a high-fee nLockTime in the block you are creating. 00:21 Luke-Jr petertodd: but nLockTime only sets a minimum time, it cannot set a maximum 00:22 petertodd but that's it, if I have a 1BTC fee tx, with nLockTime expiring in two hours, why not take the increased orphan chance and set nTime on my block to two hours ahead/ 00:22 petertodd ? 00:22 petertodd yet if we allow that incentive, it's very bad for consensus 00:23 gmaxwell ha. We can fix. 00:23 gmaxwell it's a soft forking fix. 00:23 gmaxwell use the last blocks ntime, not this one. 00:23 Luke-Jr is sipa's secp256k1 branch reasonably stable? 00:23 petertodd gmaxwell: that's what I said... 00:24 gmaxwell petertodd: sorry I just read the last couple lines. 00:24 Luke-Jr petertodd: AFAIK we already don't relay transactions with time in the future? 00:24 gmaxwell petertodd: well I agree. (or not even the last block— it could use the minimum time) 00:24 petertodd gmaxwell: The problem is, that's only a fix if mining power is well distributed, it actually makes things worse because if there is a lot of profit to be gained the miners with a lot of hashing power still have the incentive, and it's to a much greater degree. (their orphan rate is less) 00:24 Luke-Jr gmaxwell: the minimum time will be earlier than the last block's :p 00:25 gmaxwell Luke-Jr: sure, but that doesn't change it really. Presumably if people start locking in the future miners will run nodes that take what they get and selfishly horde them, creating incentives for all miners to run good collection networks. 00:25 petertodd Luke-Jr: sure, but there are lots of ways to learn that a tx exists 00:26 gmaxwell petertodd: one of the reasons that the min is important there is because (1) it's hard to advance, and (2) when you advance it you raise the difficulty. 00:26 petertodd gmaxwell: I was working on figuring out the expected return - the math is really ugly 00:27 gmaxwell petertodd: a worst case expected return may be easier. 00:27 petertodd gmaxwell: Worst case is easy - your block is orphaned. 00:28 petertodd gmaxwell: See the issue is that once I find a block, the other side needs to find two blocks to beat me. As time goes on more of the other sides hashing power will accept my from the future block as valid, so then you get the next level where the remainder needs three blocks and so on. 00:28 petertodd gmaxwell: Pretty sure it can't be done as a closed-form equation. 00:30 petertodd gmaxwell: I don't think minimum time works either, because you still get to manipulate it by creating blocks in the future, although the ability too is definitely less. If I could show you'd need 50% hashing power to do anything interesting I'd be set. 00:31 Luke-Jr petertodd: hmm, is block-uneconomic-utxo-creation basically just an older revision of what Gavin did in 0.8.2? 00:31 gmaxwell petertodd: moving the minimum time forward needs the coperation of 50% of the hashpower over the small median window. 00:32 petertodd Luke-Jr: It's what Gavin did
Re: [bitcoin-dev] Splitting BIPs
I posted a new draft of the proposal: http://blockhawk.net/bitcoin-dev/bipwiki.html The subsections still need to be fleshed out a bit more. I'd love any comments or suggestions. On Mon, Aug 24, 2015, 4:30 PM Eric Lombrozo elombr...@gmail.com wrote: Also, the current type attribute needs modification. There are different degrees of standard. Just because a lot of people do X doesn't need to mean that doing X is officially endorsed by any other devs. At most levels below 1, disagreements might be entirely tolerable for many things. On Mon, Aug 24, 2015, 2:06 PM Eric Lombrozo elombr...@gmail.com wrote: Seems like a lot of effort and goodwill is being wasted on contention over things we don't really need to agree upon. In order to help us better prioritize, I propose adding an extra attribute to BIPs indicating their level which is split into five as follows: 1. Consensus (hard/soft fork) 2. Peer Services 3. RPC 4. Implementations 5. Applications I posted an example of what such a table might look like here: http:// blockhawk.net/bitcoin-dev/bipwiki.html If other folks also think this is a good idea I'll start working on a BIP draft for this. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Questiosn about BIP100
20th percentile, though there is some argument to take the 'mode' of several tranches On Thu, Aug 27, 2015 at 11:07 AM, Andrew C achow...@gmail.com wrote: I have been reading the pdf and one thing I can't figure out is what you mean by most common floor. Is that the smallest block size that has a vote or the block size with the most votes or something else? On Mon, Aug 24, 2015 at 10:40 AM Jeff Garzik jgar...@gmail.com wrote: Great questions. - Currently working on technical BIP draft and implementation, hopefully for ScalingBitcoin.org. Only the PDF is publicly available as of today. - Yes, the initial deployment is in the same manner as size votes. On Fri, Aug 21, 2015 at 7:38 PM, Andrew C via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hi all, Is there any client or code that currently implements BIP 100? And how will it be deployed? WIll the initial fork be deployed in the same manner that the max block size changes are deployed described in the bip? Thanks ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] CLTV/CSV/etc. deployment considerations due to XT/Not-BitcoinXT miners
I have changed BIPS 112 and 113 to reflect this amended deployment strategy. I'm beginning to think the issues created by Bitcoin XT are so serious it probably deserves converting OPs text into an informational BIP. On Thu, Aug 20, 2015 at 6:42 PM, Mark Friedenbach via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: No, the nVersion would be = 4, so that we don't waste any version values. On Thu, Aug 20, 2015 at 10:32 AM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: 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 CLTV/CSV/etc. miners running Bitcoin Core would create blocks with nVersion=8, 0b1000. From the perspective of the CLTV/CSV/etc. IsSuperMajority() test, XT/Not-Bitcoin-XT miners would be advertising blocks that do not trigger the soft-fork. For the perpose of soft-fork warnings, the highest known version can remain nVersion=8, which is triggered by both XT/Not-Bitcoin-XT blocks as well as a future nVersion bits implementation. Equally, XT/Not-Bitcoin-XT soft-fork warnings will be triggered, by having an unknown bit set. When nVersion bits is implemented by the Bitcoin protocol, the plan of setting the high bits to 0b001 still works. The three lowest bits will be unusable for some time, but will be eventually recoverable as XT/Not-Bitcoin-XT mining ceases. Equally, further IsSuperMajority() softforks can be accomplished with the same masking technique. This option does complicate the XT-coin protocol implementation in the future. But that's their problem, and anyway, the maintainers (Hearn/Andresen) has strenuously argued(5) against the use of soft-forks and/or appear to be in favor of a more centralized mandatory update schedule.(6) If you are going to mask bits, would you consider to mask all bits except the 4th bit? So other fork proposals may use other bits for voting concurrently. And as I understand, the masking is applied only during the voting stage? After the softfork is fully enforced with 95% support, the nVersion will be simply =8, without any masking? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations
On Thu, Aug 27, 2015 at 11:08:32PM +0100, Btc Drak wrote: This BIP was assigned number 113. I have updated the text accordingly and added credits to Gregory Maxwell. Please see the changes in the pull request: https://github.com/bitcoin/bips/pull/182 On Thu, Aug 27, 2015 at 11:11:10PM +0100, Btc Drak via bitcoin-dev wrote: I have changed BIPS 112 and 113 to reflect this amended deployment strategy. I'm beginning to think the issues created by Bitcoin XT are so serious it probably deserves converting OPs text into an informational BIP. I thought we had decided that the masking thing doesn't work as intended? To recap, XT nodes are producing blocks with nVersion=0b001...111 You're suggesting that we apply a mask of ~0b001...111 then trigger the soft-fork on nVersion = 0b0...100 == 4, with miners producing blocks with nVersion=0b0...1000 That will work, but it still uses up a version bit. The reason why is blocks with nVersion=0b001...000 - the intended deployment of the nVersion bits proposal - will be rejected by the nVersion = 4 rule, hard-forking them off the network. In short, we have in fact burnt a version bit unnecessarily. If you're going to accept hard-forking some people off the network, why not just go with my stateless nVersion bits w/ time-expiration proposal instead? The only case where it leads to a hard-fork is if a soft-fork has been rejected by the time the upgrade deadline is reached. It's easy to set this multiple years into the future, so I think in practice it won't be a major issue for non-controversial soft-forks. Equally, spending the time to implement the original stateful nVersion bits proposal is possible as well, though higher risk due to the extra complexity of tracking soft-fork state. -- 'peter'[:-1]@petertodd.org 08ba8215b2b644e33a98a762fd40710bc5e8c7f1b0e78375 signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
So I've created 2 new repositories with changed rules regarding sequencenumbers: https://github.com/maaku/bitcoin/tree/sequencenumbers2 This repository inverts (un-inverts?) the sequence number. nSequence=1 means 1 block relative lock-height. nSequence=LOCKTIME_THRESHOLD means 1 second relative lock-height. nSequence=0x8000 (most significant bit set) is not interpreted as a relative lock-time. https://github.com/maaku/bitcoin/tree/sequencenumbers3 This repository not only inverts the sequence number, but also interprets it as a fixed-point number. This allows up to 5 year relative lock times using blocks as units, and saves 12 low-order bits for future use. Or, up to about 2 year relative lock times using seconds as units, and saves 4 bits for future use without second-level granularity. More bits could be recovered from time-based locktimes by choosing a higher granularity (a soft-fork change if done correctly). On Tue, Aug 25, 2015 at 3:08 PM, Mark Friedenbach m...@friedenbach.org wrote: To follow up on this, let's say that you want to be able to have up to 1 year relative lock-times. This choice is somewhat arbitrary and what I would like some input on, but I'll come back to this point. * 1 bit is necessary to enable/disable relative lock-time. * 1 bit is necessary to indicate whether seconds vs blocks as the unit of measurement. * 1 year of time with 1-second granularity requires 25 bits. However since blocks occur at approximately 10 minute intervals on average, having a relative lock-time significantly less than this interval doesn't make much sense. A granularity of 256 seconds would be greater than the Nyquist frequency and requires only 17 bits. * 1 year of blocks with 1-block granularity requires 16 bits. So time-based relative lock time requires about 19 bits, and block-based relative lock-time requires about 18 bits. That leaves 13 or 14 bits for other uses. Assuming a maximum of 1-year relative lock-times. But what is an appropriate maximum to choose? The use cases I have considered have only had lock times on the order of a few days to a month or so. However I would feel uncomfortable going less than a year for a hard maximum, and am having trouble thinking of any use case that would require more than a year of lock-time. Can anyone else think of a use case that requires 1yr relative lock-time? TL;DR On Sun, Aug 23, 2015 at 7:37 PM, Mark Friedenbach m...@friedenbach.org wrote: A power of 2 would be far more efficient here. The key question is how long of a relative block time do you need? Figure out what the maximum should be ( I don't know what that would be, any ideas?) and then see how many bits you have left over. On Aug 23, 2015 7:23 PM, Jorge Timón bitcoin-dev@lists.linuxfoundation.org wrote: On Mon, Aug 24, 2015 at 3:01 AM, Gregory Maxwell via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: 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, higher resolution numbers for a sharechain commitement. No, I don't think anybody thought about this. I just explained this to Pieter using for example, 10 instead of 1. He suggested 600 increments so that it is more similar to timestamps. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
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 incentive to 51% attack due to this reason. The incentive to 51% attack will exist when you use any value other than 50-percentile. The further it is from 50, the bigger the incentive. Having said that, I don't think it is an absolutely bad idea to use a value other than 50-percentile. The exact value is debatable. However, if you use something other than median, you should make it symmetrical. For example, the block size will increase if the 20-percentile is bigger than the current limit, and the block size will decrease if the 80-percentile is smaller than the current limit. Jeff Garzik via bitcoin-dev 於 2015-08-27 16:49 寫到: 20th percentile, though there is some argument to take the 'mode' of several tranches On Thu, Aug 27, 2015 at 11:07 AM, Andrew C achow...@gmail.com wrote: I have been reading the pdf and one thing I can't figure out is what you mean by most common floor. Is that the smallest block size that has a vote or the block size with the most votes or something else? On Mon, Aug 24, 2015 at 10:40 AM Jeff Garzik jgar...@gmail.com wrote: Great questions. - Currently working on technical BIP draft and implementation, hopefully for ScalingBitcoin.org. Only the PDF is publicly available as of today. - Yes, the initial deployment is in the same manner as size votes. On Fri, Aug 21, 2015 at 7:38 PM, Andrew C via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hi all, Is there any client or code that currently implements BIP 100? And how will it be deployed? WIll the initial fork be deployed in the same manner that the max block size changes are deployed described in the bip? Thanks ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [1] Links: -- [1] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, On 08/27/2015 06:39 AM, prabhat via bitcoin-dev wrote: Fine point. So where is the solution? What to do? You could study bitcoin some more and understand what it is instead of proposing to implement AML-KYC in bitcoin which shows vast ignorance about it. That's probably what you should do. Prabhat Kumar Singh Prabhat Kumar Singh On Thu, Aug 27, 2015 at 6:58 PM, Gavin Andresen gavinandre...@gmail.com mailto:gavinandre...@gmail.com wrote: Have you talked with anybody at the Bitcoin Foundation about this proposal? As Chief Scientist of the Foundation, I am strongly opposed to any proposal that puts the Foundation in a position of centralized authority, so this is unacceptable: The Bitcoin Foundation will act as fair play party and enforcement body to control the misuse of vast financial powers which bitcoin has. The idea that a central organization can be trusted to keep secrets secure is just fundamentally wrong. In the very recent past we have seen government organizations fail in that task (the NSA, the OPM) and we see commercial organizations that SHOULD be highly motivated to do a good job also fail (e.g. the Ashley Madison leak). Even if it were technically possible, I would be opposed because decentralization is a bedrock principle of Bitcoin. -- -- Gavin Andresen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev - -- http://abis.io ~ a protocol concept to enable decentralization and expansion of a giving economy, and a new social good https://keybase.io/odinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV38K+AAoJEGxwq/inSG8CTK8IAI3WMVX4Ajk4PraPsCZqugrv OjuQXc13K4/lf+FSxerzuNQy2ppLnl4jS7/5kJ0kYRHf0FGn7nMvk6NX1bze4P4S iAyP6oUvPv/LdX9XMettKo4S6B/Nrl8f3q9sRmW1ZicpvhTLrzIGXQvmnX3M115o h+mtGMRcfL2znjZIoiAE9jEtTt3ZW3yswk4eGOA5wAoD5VAuBmVWBE61ZGqAFwW+ 7EskK96ZQnlroKnk47sfn2V3vemUijpXtZItcuVSENAAKwhC/rMG2hLSFOFgk608 owYTLQcSX6DITNPpzb0/TMHwiuAog4YJ260QwY95SFyPARhN167SzR8IWKQU+MQ= =t9+J -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin
I've done some work in this area. see http://coinvalidation.com/ it's currently shelved due to lack of legal and regulatory framework. 1. this should not be directly implemented on the protocol level. I believe its Jeff Garzik who once said stolen bitcoins is a legal problem, not a technical one. Legal problems are not technical problems. 2. it is the responsibility of company and individuals to answer questions. example, stolen bitcoins gets send to address X, and address X is a payment address of company Y. it is company Y's responsibility to answer to corresponding agencies responsible. What actions comes out of that is yet to be determent. other examples such as, you are using a wallet app, and sending bitcoin payments to a known malicious address. ( e.g. crypto-locker or other malware address that replaces the output address.), does the wallet app warn its users? Again, while these are not technical problems, they will need answers eventually. I'll be happy to discuss further off this mailing list as it is off-topic. On Thu, Aug 27, 2015 at 10:00 PM, odinn via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 No. On 08/27/2015 01:10 AM, prabhat via bitcoin-dev wrote: Hi, I am proposing to create a AML-KYC module to control the network and also qualify use cases in OFAC compliant way. Here is the attached doc. Please provide your feedback and suggestions. Best, Prabhat Kumar Singh ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev - -- http://abis.io ~ a protocol concept to enable decentralization and expansion of a giving economy, and a new social good https://keybase.io/odinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV38DGAAoJEGxwq/inSG8CkYkIAJwHOnjesbq+UHogUkGJsuph 2ipSIcBEzbeVH8fQ2sij5jKULE0n8J7K/DtfzzRJj+IiaYB1Ecjl0kLVQ0ug6T/8 p5iuGQ2fvt1tMOy9+ptZbOZhtjUTWWSMqmFgsPkh5s/uGHeKy/jBjYsZv4FZ57Hm DUUvGYIdaGQ2eYm4y4dLnvI0T5WFQvf0Vs4wvWZdKvD5oliSwGy4KNVIxlcGya8w FPYaDe8q0rN5Aqp4V2jjfuF4KBC8dwHa9dyHTfSPA43I1qbcIVraSdJg1lCJ/bXh rFz+MXcGmsxxzHMbv6C4y+YSET2TPuNUs4w6MVw2ZO0lYe1suWYeYvfccQA1+Uk= =17NP -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- *Yifu Guo* *Life is an everlasting self-improvement.* ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
On Thu, Aug 27, 2015 at 12:38:42PM +0930, Rusty Russell via bitcoin-dev wrote: So I'd like an IsStandard() rule to say it nLockTime be 0 if an nSequence != 0x. Would that screw anyone currently? That sentence doesn't quite parse (say it nLockTime), so please forgive me if I'm misunderstanding you. Are you saying that you want IsStandard() to require a transaction have a locktime of 0 (no confirmation delay) if any of its inputs use a non-final sequence? If so, wouldn't that make locktime useless for delaying confirmation in IsStandard() transactions because the consensus rules require at least one input be non-final in order for locktime to have any effect? Thanks, -Dave signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin
I would prefer not to download an attachment. Generally and without having the benefit of reading your document, AML and or KYC requirements are treated on a jurisdiction by jurisdiction basis. You would probably need to factor obtaining a universal agreement between all of the governments and regional enforcement bodies of the world on the nature and scope of an acceptable set of policies before attempting to attach rules to the protocol. Clearly, when one country unilaterally places politicians of another country on banned lists and vice versa, for example, would create some problems with implementation and automating checks against banned lists produced by each country. While you could apply a 'home rule' approach, you would be pushing regulatory controls down to individuals transacting between each other without having to go through any regulated intermediaries. This means you have no way to enforce KYC or verify that the details are correct unless you create a system of third party checkers in each country who would enable transactions to proceed. To overcome all of this you would probably need some identity verification system in place first and to add extra fees into the network to pay for the maintenance of the system. As has already been pointed out, the above would lead to individual coins being tainted with previous ownership details creating the possibility for blacklists rendering some coins worthless and creating the possibility of these coins being passed on to unsuspecting users. All this goes against the spirit of monetary systems, so you are back to regulating end points as and when users come into contact with regulated entities. Lastly, it might be worth knowing that criminal liability can be placed on individuals responsible for implementing AML and KYC procedures and policies that do not work or allow criminals to circumvent the systems of controls. On Thu, Aug 27, 2015 at 9:10 AM, prabhat via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hi, I am proposing to create a AML-KYC module to control the network and also qualify use cases in OFAC compliant way. Here is the attached doc. Please provide your feedback and suggestions. Best, Prabhat Kumar Singh ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin
Hi, I am proposing to create a AML-KYC module to control the network and also qualify use cases in OFAC compliant way. Here is the attached doc. Please provide your feedback and suggestions. Best, Prabhat Kumar Singh Title: A AML KYC enforcement mechanism to regulate OFAC(and similar others) from Mining ==Abstract== The document gives specification for dealing with mining and transactions in sactioned countries to follow OFAC regulations in Bitcoin. ==Motivation== For so long, miners in sanctioned countries or miners with illicit motives have been able to enmasse wealth by bitcoins which might or might not have been funding wrong doings of one or many non-mainstream social activities, like terrorism, human traffiking, drugs, rights abuse and many more of similar or advance nature. It is important for bitcoin community to realise the responsibility to put a control on such elements and at the same time uphold the values of bitcoin's decentralised and democratic money system. The same applies for transactions orgininating to or from such sanctioned countries. ==Specification== To counter this problem, an bitcoin account can be centrally created in control and/or oversight of Bitcoin Foundation which should be allowed to do 0-sum transactions with a Memo Flag of BLOCK or ALLOW. And empty memo transaction has no impact. And this should be considered in consensus protocol for transaction confirmation, to BLOCK or ALLOW transactions in an account if the immediate previous transaction is BLOCK or ALLOW in that account, respectively. ==Rationale== The Bitcoin Foundation will act as fair play party and enforcement body to control the misuse of vast financial powers which bitcoin has. The BLOCK and ALLOW is end action of a possible upstream review process for every account on the bitcoin network. The freedom of unchecked mining, poses a certain threat today and even bigger threats in future. Even if someone is BLOCKed due to certain clerical mistakes, the process has ALLOW functionality. And if law enforcement comes with more substantial reasons of BLOCKing an account, the same be done multiple times. We are a world of human beings with rationale, who have abilities to talk, listen and communicate. Therefore, a human to human touch can never be negated in however powerful computerisation. ==Backward compatibility== The new consensus protocol could seem unfavourable to some due to many reasons. After listening to all parties, even if some nodes would opt to stay in old protocol, they won't be able to join the new protocol ever. This would be a hard fork and natural cleanup of bitcoin protocol from illicit miners and users. ==Implementation== The implementation is in progress. The detail code will be shared soon. ==Acknowledgements== It is better to be violent, if there is violence in our hearts, than to put on the cloak of nonviolence to cover impotence.- Mahatma Gandhi ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIPS proposal for implementing AML-KYC in bitcoin
Thanks for the comments and feedback. I have previously read those threads as suggested by some members. In relation with transactions, I do agree with suggestions that they should be left on their own, and assumed that people would work in the best interest of themselves and society. Everything is debatable, but let's agree with it. But for miners, I can think of no other option to stop those who are hashing and winning blocks+transaction fees and not in safe country list(directly or indirectly). Some have asked for proofs, but that is tough to substantiate. I have hints, honestly. Would you sit idle if Haqqani network is funded by bitcoin mining? We have created a billion dollar market by bitcoin and ,sadly, for everyone without borders. Sick, I am saying this, but freedom is more of responsibility than celebrations of open hugs. And those who don't care about it are threat for you and us, equally. Folks, suggest something, scrap my idea, but let's build something to save this ecosystem, otherwise it is impossible to realise this dream of decentralized currency. Other coins and protocols are there who may implement something, and egoists always meet the ashes. Criticize with open mind. Best, Prabhat Kumar Singh On Thu, Aug 27, 2015 at 3:43 PM, Chris D'Costa chrisjdco...@gmail.com wrote: What evidence do you have that there is 'illicit miners and users' and that there are no illicit users of the non-bitcoin financial systems? I can buy drugs openly in Amsterdam for Euros, but cannot in the UK for sterling. Is the act of buying drugs somewhere in the world illicit activity or not? On 27 August 2015 at 10:10, prabhat via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hi, I am proposing to create a AML-KYC module to control the network and also qualify use cases in OFAC compliant way. Here is the attached doc. Please provide your feedback and suggestions. Best, Prabhat Kumar Singh ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
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 is impossible to realise this dream of decentralized currency. Other coins and protocols are there who may implement something, and egoists always meet the ashes. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
