<unnamed>

Public Key

npub105eg2ny7gs448umtlsn4ns4slc5q3se8wpnzhtr22j8sgdrv2q7stlgz5a

Profile Code

nprofile1qqs86v59fj0yg26n7d4lcf6ec2c0u2qgcvnhqe3t4349frcyx3k9q0gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds2dkcca

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:38:15 CEST

- reply

📅 Original date posted:2015-08-27
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/ea799a7b/attachment.html>

2023-06-07 19:37:49 CEST

- reply

📅 Original date posted:2015-08-21
📝 Original message:Interesting.
Unless I misunderstand the proposal, you would have to factor a way to deal
with miner cartel behavior. A few emails every week and the larger miners
could collude to set prices.
With that figured, then your voting proposal could be triggered by a moving
day block average which takes into account capacity for any given period,
plus a level of headroom for unexpected spikes. The issue with this is
forward planning is more important, especially when the moving average is
longer than a week.
Credit card providers and retailers use a number of factors to plan for
capacity on a regional basis. From previous years figures, long-term
weather forecasts, annual calendar events, one off events, etc. A global
currency can't use many of these tools for forward planning.
E.g. religious holidays are among the biggest events for transactions; if
we take Christmas, your proposal could work out a capacity during a quiet
period in November leading to a downward adjustment which then sees
transactions getting maxed out during the two weeks before Christmas eve.
You could then have an upward adjustment, but people stop spending on
Christmas day.
These are human factors that need to be considered.
On Fri, Aug 21, 2015 at 11:22 PM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I wanted to offer a potential way to adjust the block size limit in a
> democratic way without making it easy to game. This is meant only as a
> starting point for a general idea. Thresholds and exact figures and
> the details of the algorithm are up for debate, and possibly some
> formula based determination.
>
> The living document is currently a gist available at
> https://gist.github.com/btcdrak/1c3a323100a912b605b5
>
>
> <pre>
> BIP: XX
> Title: Consensus based block size retargeting algorithm
> Author: BtcDrak <btcdrak at gmail.com>
> Status: Draft
> Type: Standards Track
> Created: 2015-08-21
> </pre>
>
> ==Abstract==
>
> A method of altering the maximum allowed block size of the Bitcoin
> protocol using a consensus based approach.
>
> ==Motivation==
>
> There is a perception that Bitcoin cannot easily respond to raising
> the blocksize limit if popularity was to suddenly increase due to a
> mass adoption curve, because co-ordinating a hard fork takes
> considerable time, and being unable to respond in a timely manner
> would irreparably harm the credibility of bitcoin.
>
> Additionally, predetermined block size increases are problematic
> because they attempt to predict the future, and if too large could
> have unintended consequences like damaging the possibility for a fee
> market to develop as block subsidy decreases substantially over the
> next 9 years; introducing or exacerbating mining attack vectors; or
> somehow affect the network in unknown or unpredicted ways. Since fixed
> changes are hard to deploy, the damage could be extensive.
>
> Dynamic block size adjustments also suffer from the potential to be
> gamed by the larger hash power.
>
>
> ==Rationale==
>
> By introducing a cost to increase the block size ensures the mining
> community will collude to increase it only when there is a clear
> necessity, and reduce it when it is unnecessary. Rogue miners cannot
> force their wishes so easily because not only will they have to pay
> extra a difficulty target, then can be downvoted at no cost by the
> objecting hash power.
>
>
> ==Specification==
>
> The initial "base block size limit" shall be 1MB.
>
> Miners can vote for a block size increase by signalling the proposed
> percentage increase of the "base block size limit" in the coinbase
> field. For the vote to be considered valid the block they mine must
> meets a difficulty target which is proportionally larger than the
> standard difficulty target based on the percentage increase they voted
> for. If a miner does not vote, or the vote is invalid, it shall be
> counted as a vote for no change.
>
> Miners may vote the size down by signalling in the coinbase field
> without paying a difficulty penalty.
>
> Every 2016 blocks, the maximum allowed block size will be recalculated
> by the average of all votes in the last 2016 blocks, i.e. sum each
> vote from each block and divide by 2016 then multiply by the base
> block size limit. This will redefine the base block size limit for the
> next 2016 blocks.
>
> Blocks that are larger than the calculated base block size limit are
> invalid and MUST be rejected.
>
> The maximum change up or down each retargeting period shall be limited
> to 10% of the base block size limit.
>
> The maximum block size may not increase above 8MB.
>
> Votes shall be cast by adding the following human readable multiplier
> to the coinbase string “/BXn.nnn/” where valid votes would exist
> between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10%
> increase). “/BX1.000/” would be a vote for no change. Invalid votes
> will be counted as a vote for no change: “/BX1.000/”.
>
>
> ==Acknowledgements==
>
> This proposal is based on ideas and concepts derived from the writings
> of Meni Rosenfeld and Gregory Maxwell.
>
>
> ==Copyright==
>
> This work is placed in the public domain.
> _______________________________________________
> 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: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150822/c9e0bb54/attachment.html>

2023-06-07 19:36:30 CEST

- reply

📅 Original date posted:2015-08-17
📝 Original message:Hello,
Here we propose a long-term solution to replace mining rewards and
transactions fees.
BIP [104] is currently a discussion draft only.
https://drive.google.com/file/d/0BwEbhrQ4ELzBSXpoUjRkc01QUGc/view?usp=sharing
Views and feedback welcome.
Regards,
Ahmed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/e68c7083/attachment.html>

2023-06-07 19:34:45 CEST

- reply

📅 Original date posted:2015-08-20
📝 Original message:Add:
For - If everyone agrees an increase is required at some point, The longer
you leave it the greater the numbers who have to upgrade
Against - Insufficient testing before moving to production ready releases
sets a bad precedent
On Thu, Aug 20, 2015 at 10:11 PM, Elliot Olds via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Aug 14, 2015 at 4:57 PM, Jorge Timón <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> To be clear, these two are just my personal lists of arguments on
>> "each side" to clear my mind and try to be perfectly objective.
>> [...]
>> Here's the updated both-thread lists:
>>
>>
>> http://0bin.net/paste/igHZMgeoIbYjCJd9#ovaOUlSAKvQYT2p3VXuIuUmNk2XyLH-GnjR5NZMZgFb
>
>
> I thought this was a good idea, so I turned my personal notes into a site
> attempting to list all the strongest arguments and counterarguments on the
> block size debate. I made mine a bit more detailed.
>
> Here's the site: https://sites.google.com/site/bitcoinblocksizedebate/
>
> Feedback welcome.
>
>
> _______________________________________________
> 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: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150820/31894e56/attachment.html>

2023-06-07 17:49:14 CEST

- reply

2023-06-07 17:46:40 CEST

- reply