Ahmed Zsales [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-08-17 to 2015-09-02
💬 Posted a total of 17 messages
📚 Participated in the following categories: bitcoin-dev, 104, xxxx
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub105eg2ny7gs448umtlsn4ns4slc5q3se8wpnzhtr22j8sgdrv2q7stlgz5a

Profile Code

nprofile1qqs86v59fj0yg26n7d4lcf6ec2c0u2qgcvnhqe3t4349frcyx3k9q0g60ve8t

Author Public Key

npub105eg2ny7gs448umtlsn4ns4slc5q3se8wpnzhtr22j8sgdrv2q7stlgz5a

Show more details

Last Notes

2023-06-07 17:39:06

- reply

📅 Original date posted:2015-09-02
📝 Original message:Thanks Warren, very good feedback.
To avoid taking up too much of everyone's time at this point, I
think Wladimir's suggestion of placing this in a BIP advisory box for a
while is a good one. We did indicate that this might take a while to
gestate.
It is probably for us to do some further investigations and possibly engage
some input from a few miners. We don't want to play at being lawyer, but
our review does point towards this being something worth coming back to.
In terms of citation, we did reference a case called *Feist*. We also found
some general database protection details which are relevant to the USA, if
you need any bed time reading:
http://copyright.gov/reports/dbase.html
For now, thanks to everyone for feedback and comments.
Regards,
Ahmed
On Wed, Sep 2, 2015 at 9:56 AM, Warren Togami Jr. via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I am skeptical that any license for the blockchain itself is needed
> because of the possibility that the blockchain is not entitled to copyright
> protection. While I am not a lawyer, I have stared hard at the copyright
> doctrine of the U.S. in multiple law school Intellectual Property courses
> and during my previous career in Open Source Software where copyright
> matters a great deal.
>
> As each owner of a
>> coin makes a transfer by digitally signing a hash of the previous
>> transaction along with the
>> new owner’s public key, the block chain is a perpetual compilation of
>> unique data.
>> *It is therefore compiled in a creative and non-obvious way.* In the
>> USA, for example, these
>> attributes confer legal protections for databases which have been ruled
>> upon by the courts.
>
>
> This portion of your paper I believe is not true and requires citations if
> you want to be convincing. Is it truly "creative and non-obvious"? My
> understanding under at least U.S. law, the blockchain may not be entitled
> to copyright protection because a compilation created in a mechanical
> manner is not a creative work of a human.
>
> I suppose a transaction could contain a "creative" element if it contains
> arbitrary bytes of a message or clever script. For the most part though
> most of what you call "digitally signing a hash of the previous transaction
> along with the new owner’s public key" is purely the result of a mechanical
> process and really is not creative. Furthermore, even if that output were
> "non-obvious", obviousness has nothing to do with copyrightability.
>
> Your license is correct in intent in attempting to exclude from the
> royalty free grant works within the blockchain that themselves may be
> subject to copyright of third parties. The elements within the blockchain
> may be entitled individually to copyright if they are in any way a creative
> work of a human, but as a compilation I am doubtful the blockchain itself
> is entitled to copyright.
>
> I understand copyright with respect to databases can be different under
> other jurisdictions. Your paper mentions the European database law that is
> indeed different from the U.S. Your paper is incomplete in scholarly and
> legal citations. I myself and we as a community don't know enough. I
> suppose this topic merits further study.
>
> Warren Togami
>
> On Tue, Sep 1, 2015 at 6:30 AM, Ahmed Zsales via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hello,
>>
>> We believe the network requires a block chain licence to supplement the
>> existing MIT Licence which we believe only covers the core reference client
>> software.
>>
>> Replacing or amending the existing MIT Licence is beyond the scope of
>> this draft BIP.
>>
>> Rationale and details of our draft BIP for discussion and evaluation are
>> here:
>>
>>
>> https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
>>
>> Regards,
>>
>> Ahmed
>>
>> _______________________________________________
>> 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: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150902/e322b19b/attachment.html>

2023-06-07 17:39:05

- reply

📅 Original date posted:2015-09-01
📝 Original message:Your points are interesting, but they are covered:
https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
Your general point: "Better just put everything in public domain" is the
reason why Bitcoin works, but taken to the extreme it is an argument
against attempts to obfuscate transaction ownership.
Regards,
Ahmed
On Tue, Sep 1, 2015 at 11:20 PM, Natanael <natanael.l at gmail.com> wrote:
>
> Den 2 sep 2015 00:03 skrev "Btc Drak via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org>:
> >
> > I think it gets worse. Who are the copyright owners (if this actually
> > applies). You've got people publishing transaction messages, you've
> > got miners reproducing them and publishing blocks. Who are all the
> > parties involved? Then to take pedantry to the next level, does a
> > miner have permission to republish messages? How do you know? What if
> > the messages are reproducing others copyright/licensed material? It's
> > not possible to license someone else's work. There are plenty rabbit
> > holes to go down with this train of thought.
>
> Worse yet - transaction malleability creates derative works with multiple
> copyright holders (the original one, plus the author of the modification).
> Is that even legal to do? What to do if a miner unknowingly accepts an
> illegally modified transaction in a block? And can he who modified it ALSO
> sue anybody replicating the block for infringement?
>
> Better just put everything in public domain, or the closest thing to it
> you can get. Copyright in the blockchain is essentially the DVDCSS illegal
> prime mess all over again, but in a P2P network.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/1be425e9/attachment.html>

2023-06-07 17:39:04

- reply

📅 Original date posted:2015-09-01
📝 Original message:To avoid repetition, we have actually covered the general points and
questions you have raised in the draft BIP, which includes a draft licence
to assist discussions:
https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
Regards,
Ahmed
On Tue, Sep 1, 2015 at 11:02 PM, Btc Drak <btcdrak at gmail.com> wrote:
> I think it gets worse. Who are the copyright owners (if this actually
> applies). You've got people publishing transaction messages, you've
> got miners reproducing them and publishing blocks. Who are all the
> parties involved? Then to take pedantry to the next level, does a
> miner have permission to republish messages? How do you know? What if
> the messages are reproducing others copyright/licensed material? It's
> not possible to license someone else's work. There are plenty rabbit
> holes to go down with this train of thought.
>
> On Tue, Sep 1, 2015 at 8:36 PM, Ahmed Zsales via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > That is a very good point.
> >
> > We considered whether data existing before a licence change would be
> > covered, but we hadn't factored the potential need for gaining
> permissions
> > for a change to be considered effective.
> >
> > We have proposed that miners be the main beneficiaries of licensing and
> > there is a consideration on whether they should vote to adopt the new
> terms.
> > While not the preferred route, that would overcome any issues to what is
> an
> > otherwise honest 'error and omission.' There doesn't seem to be anyone
> who
> > could claim to have suffered any economic losses so this may not be an
> > issue. It merits further investigation.
> >
> > The block chain is in perpetual change, so the sooner a change is agreed
> > upon, if at all, the more data it will cover without any reservations. At
> > any rate, we believe the changes would be considered effective on a
> > retrospective basis.
> >
> >
> > On Tue, Sep 1, 2015 at 7:12 PM, Btc Drak <btcdrak at gmail.com> wrote:
> >>
> >> Without commenting on your proposal at all, the general problem with
> >> licensing after the fact is you require the permission of every
> >> copyright holder in order to make the change.
> >>
> >>
> >>
> >> On Tue, Sep 1, 2015 at 2:30 PM, Ahmed Zsales via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> > Hello,
> >> >
> >> > We believe the network requires a block chain licence to supplement
> the
> >> > existing MIT Licence which we believe only covers the core reference
> >> > client
> >> > software.
> >> >
> >> > Replacing or amending the existing MIT Licence is beyond the scope of
> >> > this
> >> > draft BIP.
> >> >
> >> > Rationale and details of our draft BIP for discussion and evaluation
> are
> >> > here:
> >> >
> >> >
> >> >
> https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
> >> >
> >> > Regards,
> >> >
> >> > Ahmed
> >> >
> >> > _______________________________________________
> >> > 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: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/605b71cf/attachment.html>

2023-06-07 17:39:03

- reply

📅 Original date posted:2015-09-01
📝 Original message:This is good feedback. Thank you.
Very briefly:
> "To put a license on something you have to own it in the first place." ##
The block chain is a database. There are laws to protect databases. We have
suggested who might be best placed to be assigned rights to the block chain
and more importantly why.
> "A copyright is about protecting revenue" ## Not always. It can also be
about saying you have a right to something and you give up those rights.
There are likely to be many examples where this could be applied, for
example - if you transact with someone and government agencies develop the
means to reveal your transaction, a licence gives protections which might
otherwise not be there in the absence of a licence. The MIT licence does
something similar - the Core developers give up their rights to revenue
from the software. Not wishing to go down rabbit hole, why not just remove
the MIT licence?
> "it is not up to you, or anyone else, to come up with the form of a
license to control data owned by someone else." ## It is up to us to
produce some guidance and context to assist with the BIP discussion
process. If anyone else has any suggestions on wording or access to legal
advice, that will be helpful.
> "Then the miner can charge a fee for any public block explorer that wants
to display the block at their web site" ## I would oppose any wording that
attempted to do anything of the sort. Bitcoin works because the block chain
is in the public domain. We have included references to royalty free use of
the data.
> "If there are rights it is up to miners to come up with their license."
## The original reference client did everything. A block chain licence was
probably not envisioned. Mining has taken a different path from that which
was intended. Nevertheless, one needs to start somewhere. The proposal to
assign rights to miners is just that, a proposal.
I would just like to labour the point that users pay to use the network,
but they have no defined rights, anywhere.
Regards,
Ahmed
On Tue, Sep 1, 2015 at 11:42 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The general points and questions you have raised are covered in the
>> draft BIP:
>>
>
> No, the BIP makes some weird statements that don't really make sense.
>
> Number one rule here: To put a license on something you have to own it in
> the first place.
>
> Let's say for the sake of argument that Miners own the copyright on a
> block they find (as pointed out something like does not normally get
> copyright protection but let's just pretend). Then the miner can charge a
> fee for any public block explorer that wants to display the block at their
> web site. They could also try to collect a fee from anyone who distributes
> it (like Bitcoin users using p2p to distribute the blockchain). A
> copyright is about protecting revenue. Is there some other purpose of
> putting a license on intellectual property?
>
> Also, it is not up to you, or anyone else, to come up with the form of a
> license to control data owned by someone else. How can you force miners
> or users to use any specific license that you come up with?
>
> There are a number of other weird statements that really don't make any
> kind of sense:
>
> "In the USA, for example, these attributes confer legal protections for
> databases which have been ruled upon by the courts." I have no idea what
> this means or what court cases you are referring to.
>
> "The Bitcoin Core Miners" is not an identifiable entity and cannot own
> intellectual property rights. What is the purpose of you putting a notice
> that some unidentifiable entity has some sort of rights over the blockchain
> data? You are not that entity and neither are the developers. If there
> are rights it is up to miners to come up with their license.
>
> "[users] own the rights to their individual transactions through
> cryptograph security." I have no idea what this means. It is certainly
> not intellectual property rights of anything I am familiar with. Once
> again, if the users do have intellectual rights then someone else cannot
> dictate the terms of the license. They could charge a fee for miners
> publishing their transaction data.
>
>
> Russ
>
>
> _______________________________________________
> 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/20150902/5298429e/attachment-0001.html>

2023-06-07 17:39:02

- reply

📅 Original date posted:2015-09-01
📝 Original message:Russ,
The general points and questions you have raised are covered in the draft
BIP:
https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
Regards,
Ahmed
On Tue, Sep 1, 2015 at 10:36 PM, Milly Bitcoin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> We considered whether data existing before a licence change would be
>> covered, but we hadn't factored the potential need for gaining
>> permissions for a change to be considered effective.
>>
>> We have proposed that miners be the main beneficiaries of licensing and
>> there is a consideration on whether they should vote to adopt the new
>> terms. While not the preferred route, that would overcome any issues to
>> what is an otherwise honest 'error and omission.' There doesn't seem to
>> be anyone who could claim to have suffered any economic losses so this
>> may not be an issue. It merits further investigation.
>>
>
> Like I said, you need to talk to a lawyer. What exactly would be the
> purpose of any license? How can someone be a "beneficiary" to a license
> when you can't even explain who holds the license to begin with? How do
> they "benefit?" I don't see any purpose to putting a license on the Core
> software or the blockchain because nobody can explain who actually holds
> the license and there is no mechanism to enforce any license and there is
> no revenue to be shared. The whole discussion makes no sense.
>
> Russ
>
>
>
> _______________________________________________
> 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/20150901/4ffe6be7/attachment.html>

2023-06-07 17:39:01

- reply

📅 Original date posted:2015-09-01
📝 Original message:That is a very good point.
We considered whether data existing before a licence change would be
covered, but we hadn't factored the potential need for gaining permissions
for a change to be considered effective.
We have proposed that miners be the main beneficiaries of licensing and
there is a consideration on whether they should vote to adopt the new
terms. While not the preferred route, that would overcome any issues to
what is an otherwise honest 'error and omission.' There doesn't seem to be
anyone who could claim to have suffered any economic losses so this may not
be an issue. It merits further investigation.
The block chain is in perpetual change, so the sooner a change is agreed
upon, if at all, the more data it will cover without any reservations. At
any rate, we believe the changes would be considered effective on a
retrospective basis.
On Tue, Sep 1, 2015 at 7:12 PM, Btc Drak <btcdrak at gmail.com> wrote:
> Without commenting on your proposal at all, the general problem with
> licensing after the fact is you require the permission of every
> copyright holder in order to make the change.
>
>
>
> On Tue, Sep 1, 2015 at 2:30 PM, Ahmed Zsales via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Hello,
> >
> > We believe the network requires a block chain licence to supplement the
> > existing MIT Licence which we believe only covers the core reference
> client
> > software.
> >
> > Replacing or amending the existing MIT Licence is beyond the scope of
> this
> > draft BIP.
> >
> > Rationale and details of our draft BIP for discussion and evaluation are
> > here:
> >
> >
> https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
> >
> > Regards,
> >
> > Ahmed
> >
> > _______________________________________________
> > 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/20150901/0cccdded/attachment.html>

2023-06-07 17:39:00

- reply

📅 Original date posted:2015-09-01
📝 Original message:Hello,
We believe the network requires a block chain licence to supplement the
existing MIT Licence which we believe only covers the core reference client
software.
Replacing or amending the existing MIT Licence is beyond the scope of this
draft BIP.
Rationale and details of our draft BIP for discussion and evaluation are
here:
https://drive.google.com/file/d/0BwEbhrQ4ELzBMVFxajNZa2hzMTg/view?usp=sharing
Regards,
Ahmed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/06343931/attachment.html>

2023-06-07 17:39:00

- reply

📅 Original date posted:2015-09-01
📝 Original message:Thank you. We hadn't seen that before. It is an interesting discussion.
We did think about including some references to protections for private
keys while they remained in your control and you could prove as much. In
theory it should be no different to dropping money on the floor. The money
still belongs to you, even if someone else comes along and finds it. The
onus of proof is on you as the owner to demonstrate private keys are yours,
but you also need the goodwill of the person finding the money.
However, this raised a number of issues including whether finding private
keys attached to coins and moving the funds constituted theft, in which
case there are already criminal protections if you are able to track the
coins to an individual. We decided not to include anything specific in the
draft licence to keep it simple, relying instead on the generic definitions
of rights to *private transaction data* of which private keys would come
under.
Regards,
Ahmed
On Tue, Sep 1, 2015 at 2:50 PM, Bryan Bishop <kanzure at gmail.com> wrote:
> On Tue, Sep 1, 2015 at 8:30 AM, Ahmed Zsales via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> We believe the network requires a block chain licence
>
>
> Here is a previous discussion of this topic (2012):
> https://bitcointalk.org/index.php?topic=117663.0
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150901/da927d62/attachment.html>

2023-06-07 17:38:15

- 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 17:38:04

- reply

📅 Original date posted:2015-08-24
📝 Original message:Adam,
Thank you for your comments. We will address them in the next update.
Privacy is an area you have been championing for many years and your input
in this area has created the environment for Bitcoin to exist. Anonymity is
not something we would be willing to compromise, despite the general
public's endless willingness to give away their intimate life histories and
contact details to Facebook and other social media.
If you have the will to read a longish response, we have tried to expand a
little on the rationale for the type of data we believe will be useful and
valuable, in addition to broadly addressing the privacy issues.
Arguably, the greater the cryptographic protections on the ownership of a
transaction, the more value will be placed on the nature of transactions.
Without wishing to frame the conversation on specifics or particular
sectors, here are some distinctions to address some of the previously noted
Orwellian fears on attaching identity markers to Bitcoin transactions.
* We have no desire to create tools that can analyze which brand of baked
beans Bob may prefer compared to Alice. That is a matter of extreme detail
for supermarkets, their suppliers and internal point of sale systems. When
you make a store purchase, your basket of goods are wrapped up in a single
payment which appears on your credit card or bank statement. Knowing on an
aggregated basis that people spend around $120 / week on retail shopping
and that Saturday is the busiest period for that activity is more valuable
for payment processors than knowing the contents of Bob's basket of goods.
As a retailer or supplier, I would buy that data in order to plan
inventory, marketing budgets, promotional activity, staffing levels,
logistics, factory production, bank borrowing, store expansion planning,
etc.
* Now consider petrol. Bitcoin is very well suited for fuel purchases,
especially for small independent petrol filling stations. Aggregated data
would help the entire supply chain that serves the consumer, if businesses
at the front end had access to data for when demand was at peaks and
troughs. Extend that from individual petrol stations to regional, national
and international consumer purchases and you have the basis of the market
pricing oil based on demand per period and per country. Again, we don't
care that it is actually Bob who fills up every Sunday so he has enough
fuel to last him the week or to track him along his driving holiday.
* Now consider remittances. While the global headlines are that it is a
$500bn a year industry. Few people know that remittances are based on a
relatively small number of remittance corridors that make up the bulk of
the market. These corridors are based around people leaving small towns
and villages in poor areas and travelling to work in locations based on
knowing someone or a family member who used to live in their area and are
doing well in xyz location because they can see the beneficial impact on
the recipients quality of life. At the coal face, remittances are a word of
mouth grey market sector and part of the reason that WU and the like can
charge so much is because the last mile of remittances are in areas where
monetary infrastructure and logistics are difficult to serve and they can
get away with setting high prices. They prosper because they use data to
organise themselves better. Banks have no desire to serve this market
because you end up clogging up branches every Friday or Saturday with
people that transact relatively small sums compared to those that are
banked and get annoyed waiting. Having access to Bitcoin transaction data
on this sector would help Bitcoin businesses to understand the end points
of this market and serve it better and focus their promotional activities.
We have no desire to identify that Bob's cousin José is working illegally
in Texas.
These are three sectors where there are millions of small businesses that
would, for the first time, be able to access global, national and regional
industry data figures typically reserved for large businesses due to the
high cost of acquiring or commissioning research.
While increasing anonymity or having zero knowledge proofs in transactions
is desirable so that I can keep my Bitcoin salary payments private and my
membership of Ashley Madison out of the news, it would be helpful to know
that when I want to spend my salary that the world around me is organised
enough to serve my needs.
The block chain is ledger. It will contain a global data set that could end
up being one of the most valuable databases in the world. Why not use it to
fund Bitcoin's security infrastructure and growing bandwidth challenges?
Regards,
Ahmed
On Sun, Aug 23, 2015 at 5:05 PM, Adam Back <adam at cypherspace.org> wrote:
> Some comments:
>
> "(i) remove any possibility of free transactions unless
>
> associated with basic transaction data;"
>
> I believe it is not possible to prevent free transactions for the
> reason that people can pay out of band (via existing banking transfers
> to miners) or make payments to addresses belonging to miners (that are
> contingent on the requested user transaction being processed via input
> dependency) .
>
>
> I am not sure I fully understand the way you see monetisation working,
> and you do indicate this is quite far future what-if stage idea, and
> you do identify a conflict with fungibility - but I think this is
> probably quite badly in conflict with fungibility to the point of
> conflicting with many planned Bitcoin improvements? And mid term
> technical directions.
>
> I would say the long term idealised requirements are that the
> transaction itself would have cryptographic fungibility, and policy
> relating to identity for authorisation, approval in regulated
> transactions would take place at the payment protocol layer. The
> payment protocol is already seeing some use.
>
> Lightning protocol sees more of the data going point to point and so
> not broadcast nor visible for big data analytic monetisation.
>
> Adam
>
> On 22 August 2015 at 23:51, Jorge Timón
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Again, did you got a bip number asigned or did you self-assigned it
> yourself?
> >
> > On Sat, Aug 22, 2015 at 1:01 PM, Ahmed Zsales via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> Hello,
> >>
> >> In response to public and private comments and feedback, we have updated
> >> this working draft.
> >>
> >>
> https://drive.google.com/file/d/0BwEbhrQ4ELzBOUVtOHJQdlhvUmc/view?usp=sharing
> >>
> >> Update highlights:
> >>
> >> 1. Specific clarifications on replacing the Coinbase subsidy and
> >> supplementing and not replacing transaction fees.
> >>
> >> 2. Clarification on block chain overhead. The value of data mining is
> on a
> >> bell curve, so year six data will be removed every year.
> >>
> >> 3. Added references to an ability to create global, national and
> regional
> >> Bitcoin Price Indices for popular baskets of goods transacted with
> Bitcoin.
> >>
> >> 4. Added references for an ability to use structured block chain data
> for
> >> Bitcoin capacity and fork planning.
> >>
> >> 5. Removed references to price speculation.
> >>
> >> 6. Added preferences for deployment dates of January 2017 or January
> 2018.
> >>
> >> 7. Moving towards BIP format after discussion and evaluation period.
> >> Technical content will increase in due course and discussion content
> will be
> >> removed.
> >>
> >> Further views and feedback welcome.
> >>
> >> Regards,
> >>
> >> Ahmed
> >>
> >>
> >> On Mon, Aug 17, 2015 at 5:23 PM, Ahmed Zsales <ahmedzsales18 at gmail.com>
> >> wrote:
> >>>
> >>> 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
> >>>
> >>
> >>
> >> _______________________________________________
> >> 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: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150824/738f4586/attachment.html>

2023-06-07 17:38:01

- reply

📅 Original date posted:2015-08-22
📝 Original message:Hello,
In response to public and private comments and feedback, we have updated
this working draft.
https://drive.google.com/file/d/0BwEbhrQ4ELzBOUVtOHJQdlhvUmc/view?usp=sharing
Update highlights:
1. Specific clarifications on replacing the Coinbase subsidy and
supplementing *and* not replacing transaction fees.
2. Clarification on block chain overhead. The value of data mining is on a
bell curve, so year six data will be removed every year.
3. Added references to an ability to create global, national and regional
Bitcoin Price Indices for popular baskets of goods transacted with Bitcoin.
4. Added references for an ability to use structured block chain data for
Bitcoin capacity and fork planning.
5. Removed references to price speculation.
6. Added preferences for deployment dates of January 2017 or January 2018.
7. Moving towards BIP format after discussion and evaluation period.
Technical content will increase in due course and discussion content will
be removed.
Further views and feedback welcome.
Regards,
Ahmed
On Mon, Aug 17, 2015 at 5:23 PM, Ahmed Zsales <ahmedzsales18 at gmail.com>
wrote:
> 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/20150822/0bf01af1/attachment.html>

2023-06-07 17:37:49

- 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 17:36:45

- reply

📅 Original date posted:2015-08-18
📝 Original message:-> You need to take into account the reward halving, likely to be in
3Q2016. Forks and reward halving at the same time would possibly be a bad
combination.
-> The original proposed date for the fork was December 2015. It was pushed
back to January as December is a busy period for a lot of people and
businesses. Likewise, June is a busy period for people. July / August is a
good period as it is quiet because people go on holiday. A window of 2
months during holiday periods is better than starting in June. January 2016
is better, mainly because of the excessive reward halving chatter likely to
be going on..
..
> Proposal (parameters in ** are my recommendations but negotiable):
>
> 1. Today, we all agree that some kind of block size hardfork will happen
> on t1=*1 June 2016*
>
> 2. If no other consensus could be reached before t2=*1 Feb 2016*, we will
> adopt the backup plan
>
> 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but
> not before t1=*1 June 2016*, the block size is increased to s=*1.5MB*
>
> 4. If the backup plan is adopted, we all agree that a better solution
> should be found before t4=*31 Dec 2017*.
> ..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/eff641b4/attachment.html>

2023-06-07 17:36:32

- reply

📅 Original date posted:2015-08-17
📝 Original message:While Peter Todd's public mention on social media was likely meant to be
disparaging, I'll take the contribution of adding 'data mining' to the
title in future updates of the draft - thank you.
It might be ironic that he posted the remark on Twitter, where his message
will be aggregated and sold by twitter to data miners.
Twitter made $48m last year from selling data to data miners, at a 95%
growth rate on year-on-year basis. It has since spent $130m on buying a
data mining business who specialise in understanding how to mine data in
order to grow this part of their business. It is one of their more
profitable sideshows.
On Mon, Aug 17, 2015 at 7:40 PM, Btc Drak <btcdrak at gmail.com> wrote:
> You didnt reply to the list, I had emailed you privately.
>
> On Mon, Aug 17, 2015 at 7:22 PM, Ahmed Zsales <ahmedzsales18 at gmail.com>
> wrote:
> > @btc Drak, noted, thanks.
> >
> > 1. Updated - removed reference to self ascribed [104]
> >
> >
> https://drive.google.com/file/d/0BwEbhrQ4ELzBX3hCekFRSUVySWs/view?usp=sharing
> >
> >
> > @Angel Leon
> >
> > 2. Privacy issues are clearly covered.
> >
> >
> > On Mon, Aug 17, 2015 at 6:48 PM, Btc Drak <btcdrak at gmail.com> wrote:
> >>
> >> You cannot assign your own bip numbers. You have to use the form
> >> BIP-myproposal
> >>
> >> On Mon, Aug 17, 2015 at 5:39 PM, Ahmed Zsales via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>>
> >>> 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
> >>>
> >>> _______________________________________________
> >>> 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/20150818/efd44f26/attachment.html>

2023-06-07 17:36:31

- reply

📅 Original date posted:2015-08-17
📝 Original message:> @btc Drak, noted, thanks.
>
> 1. Updated - removed reference to self ascribed [104]
>
>
> https://drive.google.com/file/d/0BwEbhrQ4ELzBX3hCekFRSUVySWs/view?usp=sharing
>
>
> @Angel Leon
>
> 2. Privacy issues are clearly covered.
>
>
> On Mon, Aug 17, 2015 at 6:48 PM, Btc Drak <btcdrak at gmail.com> wrote:
>
>> You cannot assign your own bip numbers. You have to use the form
>> BIP-myproposal
>>
>> On Mon, Aug 17, 2015 at 5:39 PM, Ahmed Zsales via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> 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
>>>
>>> _______________________________________________
>>> 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/20150817/86ce5adb/attachment-0001.html>

2023-06-07 17:36:30

- 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 17:34:45

- 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>

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply