<unnamed>

Public Key

npub164fseem24m3rdpqrkq9jkx5n4d6r4wg0cthw8669gag3xszngfrsvfec7x

Profile Code

nprofile1qqsd25cvua42ac3ksspmqzetr2f6kap6hy8u9mhradz5w5gngpf5y3cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsgrp2pe

Publishing to

zd6ptui737xzscuv74zjltz6ni2ewfrnm7hq4mmvzi7tafglnsmgukyd.onion

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:42:00 UTC

- reply

📅 Original date posted:2015-10-05
📝 Original message:I fail to see how the number of confirmations has anything to do with it.
With a non-upgraded Bitcoin software during a soft fork, you get the same
blocks as everyone else, and you get the same confirmed transactions as
everyone else. So you do have the exact same "writings" as everyone else to
calculate your balance.
The problem is that some transactions that are meaningless to you are
actually meaningful to people using an upgraded Bitcoin software.
Therefore during a softfork, while you can not miss the *existence* of a
transaction, you can miss its *meaning*.
If Bitcoin was just a decentralized whiteboard for people to write on it,
that would be no problem.
But as soon as you try to actually use Bitcoin (that is, calculate the
accurate balance of a wallet in a very broad sense), you can be led a wrong
result if you did not upgrade, which is a critical problem for financial
software.
And because nothing prevent people to send you transactions of a new type,
you have no way to "opt out" of this problem.
Le lun. 5 oct. 2015 à 14:16, Jorge Timón <jtimon at jtimon.cc> a écrit :
>
> On Oct 5, 2015 2:08 PM, "Clément Elbaz" <clem.ds at gmail.com> wrote:
> >
> > It will get correct results about :
> > - the existence every block
> > - the existence of every transaction
> >
> > It will get incorrect results :
> > - about the nature of some transactions
>
> Given the assumptions above, only of transactions without enough
> confirmations.
>
> > - and therefore, about the balances of some wallets.
>
> Not if the wallet waits for enough confirmations.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/8c333034/attachment.html>

2023-06-07 17:41:59 UTC

- reply

📅 Original date posted:2015-10-05
📝 Original message:It will get correct results about :
- the existence every block
- the existence of every transaction
It will get incorrect results :
- about the *nature* of some transactions
- and therefore, about the balances of some wallets.
I fully agree with Mike here.
Le lun. 5 oct. 2015 à 14:04, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
>
> On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Well, let's agree to disagree on these two things:
> >
> > - I define "working" for a full node as verifying everything; if a node
> starts skipping bits then I'd say it's not really "working" according to
> its original design goals
>
> But assuming the hashrate majority has upgraded (and we're using 95% as
> the miner upgrade confirmation threshold to start activation, so that
> assumption seems pretty safe), a non-upgraded full node and an upgraded
> full will converge on what they see: "the most-work valid chain" will be
> the same for both. A non-upgraded full node wallet waiting for several
> confirmations (for example, 6 confirmations) will be just as safe as an
> upgraded one. In that sense, it keeps working. On top of that, nodes (of
> any kind) can use unknown block version numbers to notify the user or even
> stop working (the same notification mechanism you would use with hardforks).
>
> I agree that hardforks are necessary and we should deploy a hardfork asap
> to show the world they are indeed possible (bip99 proposes a likely
> uncontroversial one), but I still believe that is clear that softfork
> deployment is preferrable in many cases like this one.
>
> Are you going to produce a bip65 hardfork alternative to try to convince
> people of its advantages over bip65 (it is not clear to me how you include
> a new script operand via hardfork)?
> _______________________________________________
> 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/20151005/eea49466/attachment.html>

2023-06-07 17:36:29 UTC

- reply

📅 Original date posted:2015-08-17
📝 Original message:The "only bigblock" patch you want is actually available here :
https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks
Le lun. 17 août 2015 à 15:16, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> One of the comments made by the mining pools is that they won't run XT
> because it is "experimental".
>
> Has there been any consideration to making available a version of XT with
> only the blocksize changes?
>
> The least "experimental" version would be one that makes the absolute
> minimum changes to core.
>
> The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip
> changes. This saves creating a new function.
>
> Without the consensus measuring code, the patch would be even easier.
> Satoshi's proposal was just a block height comparison (a year in advance).
>
> The state storing code is also another complication. If the standard
> "counting" upgrade system was used, then no state would need to be stored
> in the database.
>
> On Wed, Jul 1, 2015 at 11:49 PM, odinn <odinn.cyberguerrilla at riseup.net>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> (My replies below)
>>
>> On 06/26/2015 06:47 AM, Tier Nolan wrote:
>> > On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam at cypherspace.org
>> > <mailto:adam at cypherspace.org>> wrote:
>> >
>> > The hard-cap serves the purpose of a safety limit in case our
>> > understanding about the economics, incentives or game-theory is
>> > wrong worst case.
>> >
>> >
>> > True.
>>
>> Yep.
>>
>> >
>> > BIP 100 and 101 could be combined. Would that increase consensus?
>>
>> Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100
>> is a better alternative to Gavin's proposal(s), but that I didn't
>> think that this should be taken to mean that I am saying one thing is
>> "superior" to Gavin's work, rather, I emphasized that Gavin work with
>> Jeff and Adam.
>>
>> At least, at this stage the things are in a BIP process.
>>
>> If the BIP 100 and BIP 101 would be combined, what would that look
>> like on paper?
>>
>> >
>> > - Miner vote threshold reached - Wait notice period or until
>> > earliest start time - Block size default target set to 1 MB - Soft
>> > limit set to 1MB - Hard limit set to 8MB + double every 2 years -
>> > Miner vote to decide soft limit (lowest size ignoring bottom 20%
>> > but 1MB minimum)
>> >
>> > Block size updates could be aligned with the difficulty setting
>> > and based on the last 2016 blocks.
>> >
>> > Miners could leave the 1MB limit in place initially. The vote is
>> > to get the option to increase the block size.
>> >
>> > Legacy clients would remain in the network until >80% of miners
>> > vote to raise the limit and a miner produces a >1MB block.
>> >
>> > If the growth rate over-estimates hardware improvements, the devs
>> > could add a limit into the core client. If they give notice and
>> > enough users update, then miners would have to accept it.
>> >
>> > The block size becomes min(miner's vote, core devs). Even if 4
>> > years notice is given, blocks would only be 4X optimal.
>> >
>> >
>> > _______________________________________________ bitcoin-dev mailing
>> > list bitcoin-dev at 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
>>
>> iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb
>> hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC
>> 5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP
>> wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH
>> YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ
>> 0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog=
>> =rtTH
>> -----END PGP SIGNATURE-----
>>
>
> _______________________________________________
> 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/307a7369/attachment.html>

2023-06-07 15:42:38 UTC

- reply

📅 Original date posted:2015-07-21
📝 Original message:As a side note, you may be interested about the 2D-Doc, which is a new
French standard used to protect documents such as address proofs or
invoice. I've been involved with it closely at work.
Every 2d-Doc include an ECDSA signature inside a 2D barcode, the key being
that the barcode is a Datamatrix and not a QR code.
If any of you can read French, the technical specification of the standard
can be found here ::
https://ants.gouv.fr/content/download/516/5665/version/4/file/ANTS_2D-Doc_CABSpec_v2.0.1_erratum.pdf
Basically, a short summary of the protected document is encoded inside the
barcode, followed by an ECDSA signature of the summary (still in the
barcode). The signature is done by an official, government-approved 2D-Doc
emitter. The 2D-Code contains a short reference (a few bytes) to designate
which emitter signed it, and then you can lookup the 2D-Doc TSL supplied by
the French government to get all the X509 Certificates from every emitters
you are interested in, in order to check the signature.
While 2D-Doc solve a very different problem than Bitcoin + BIP70, you may
be interested in knowing about it as hundred of thousands of them have been
emitted successfully while solving one of the problem you face : embedding
an ECDSA signature inside a 2D barcode.
Thank you for your time,
Clément Elbaz
Le mar. 21 juil. 2015 à 10:20, Andreas Schildbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> Hmm, the advanced QR code standards are perhaps even useful if we don't
> change anything about BIP7x. Because if we can cram more data without
> loosing scanning performance this maybe means also we can stay with the
> data we have but improve scanning?
>
>
> _______________________________________________
> 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/20150721/44c85c6b/attachment.html>

2023-06-07 15:33:54 UTC

- reply

📅 Original date posted:2015-05-08
📝 Original message:Matt : I think proposal #1 and #3 are a lot better than #2, and #1 is my
favorite.
I see two problems with proposal #2.
The first problem with proposal #2 is that, as we see in democracies,
there is often a mismatch between the people conscious vote and these same
people behavior.
Relying on an intentional vote made consciously by miners by choosing a
configuration value can lead to twisted results if their actual behavior
doesn't correlate with their vote (eg, they all vote for a small block size
because it is the default configuration of their software, and then they
fill it completely all the time and everything crashes).
The second problem with proposal #2 is that if Gavin and Mike are right,
there is simply no time to gather a meaningful amount of votes over the
coinbases, after the fork but before the Bitcoin scalability crash.
I like proposal #1 because the "vote" is made using already available data.
Also there is no possible mismatch between behavior and vote. As a miner
you vote by choosing to create a big (or small) block, and your actions
reflect your vote. It is simple and straightforward.
My feelings on proposal #3 is it is a little bit mixing apples and oranges,
but I may not seeing all the implications.
Le ven. 8 mai 2015 à 09:21, Matt Whitlock <bip at mattwhitlock.name> a écrit :
> Between all the flames on this list, several ideas were raised that did
> not get much attention. I hereby resubmit these ideas for consideration and
> discussion.
>
> - Perhaps the hard block size limit should be a function of the actual
> block sizes over some trailing sampling period. For example, take the
> median block size among the most recent 2016 blocks and multiply it by 1.5.
> This allows Bitcoin to scale up gradually and organically, rather than
> having human beings guessing at what is an appropriate limit.
>
> - Perhaps the hard block size limit should be determined by a vote of the
> miners. Each miner could embed a desired block size limit in the coinbase
> transactions of the blocks it publishes. The effective hard block size
> limit would be that size having the greatest number of votes within a
> sliding window of most recent blocks.
>
> - Perhaps the hard block size limit should be a function of block-chain
> length, so that it can scale up smoothly rather than jumping immediately to
> 20 MB. This function could be linear (anticipating a breakdown of Moore's
> Law) or quadratic.
>
> I would be in support of any of the above, but I do not support Mike
> Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the
> road without actually solving the problem, and it does so in a
> controversial (step function) way.
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/6f9d5ecd/attachment.html>

2023-06-07 15:12:02 UTC

- reply

📅 Original date posted:2014-01-08
📝 Original message:Hello all,
It seems there was a problem with my first email (thank you Mark for the
heads up), so I'll copy paste it there :
-----------------------
Hello all,
I'm designing a program that needs some metrics computed from the Bitcoin
block chain (some address balances, or the occurrence or not of a specific
transaction). The kind of infos you get from http://blockchain.info/,
provided you trust this website (my program do not).
My program should run on lightweight/embedded hardware. The execution
environment provides access to the Bitcoin network but not enough resources
to set up a trusted node along with my program. Also, my program trusts the
global Bitcoin network but no individual node.
I would need a way to ask an untrusted Bitcoin node to compute some 'metric
request' on my behalf and having the result of that metric request
validated by the network.
Is there any available or work-in-progress projects that would come close
to this need ? Or should I do it myself ? :-)
Thank you all,
Clément Elbaz
-----------------------
On Wed, Jan 8, 2014 at 8:44 PM, Clément Elbaz <clem.ds at gmail.com> wrote:
> Some more thoughts :
>
> If no such project exist yet, I thought it could work with an alternate,
> small and fixed-length 'metric request block chain' of some sort.
>
> It would temporarily stores structures defined as [metric request |
> current block number when request was made | hash of the response] instead
> of financial transactions.
>
> These structures are verifiable so it could work the same way as a regular
> financial blochchain.
>
> It should not be part of the main Bitcoin protocol but could be a plugin
> interacting with the data managed by the fullnode bitcoin software.
>
> Also, metrics requests can be expensive to compute and validate, so it
> would make sense to pay a fee everytime you ask one.
>
> Does any of this makes any sense to you ?
>
> Thanks,
>
> Clément
>
--
Clément ELBAZ
06. 09. 55. 78. 41
clem.ds at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140108/6dc30995/attachment.html>

2023-06-07 15:12:02 UTC

- reply

📅 Original date posted:2014-01-09
📝 Original message:Hi Rob,
Thank you for answering.
> So you want to 'benefit' from the network without contributing to it ?
> Not going to happen - why would anyone be interested in providing you
'free compute resources' ?
Not free. As I stated in my second email ("some more thoughts" etc.), it
seems really fitting to pay a fee to the network for every metric request
you send. 'I want to execute this request on your blockchain, and I want
the response to be approved by the Bitcoin network, and here is a fee for
all the computing trouble".
You either have the blockchain and the hardware resources to compute things
based on it, or you have addresses that takes a few bytes of data in your
environement but contains money, potentially a lot. The situation seems
plausible to me.
The thing is, as soon as there is an exchange of value (hardware computing
resources vs bitcoins) between parties that do not trust each other, there
is a need for proof of work, and thus my idea (in my second email) of a
specifc block chain that would store metric requests, current block number
when they were asked, and hash of theirs responses. This can be validated
by others nodes and as such can be published in a ledger just like bitcoin
transaction.
> Setup a node, create an API interface and have your 'app' use your API on
yoru node :p
The idea would have been actually to be able to get these computations in a
trusted way without having access to a specific trusted node. Compensating
absence of trust by providing actual money.
Anyways. I got quite a few answer privately, and after study it seems SPV
mode of bitcoinj will be just fine for my specific needs. I would have
liked the solution to be network-centric ideally (By committing to an
SPV-ready API like bitcoinj, I'm committing to languages that provide a
stable SPV API), but I'll be just fine with bitcoinj for now.
Thank you Rob and everyone for your time.
Clément
On Wed, Jan 8, 2014 at 8:44 PM, Clément Elbaz <clem.ds at gmail.com> wrote:
> Some more thoughts :
>
> If no such project exist yet, I thought it could work with an alternate,
> small and fixed-length 'metric request block chain' of some sort.
>
> It would temporarily stores structures defined as [metric request |
> current block number when request was made | hash of the response] instead
> of financial transactions.
>
> These structures are verifiable so it could work the same way as a regular
> financial blochchain.
>
> It should not be part of the main Bitcoin protocol but could be a plugin
> interacting with the data managed by the fullnode bitcoin software.
>
> Also, metrics requests can be expensive to compute and validate, so it
> would make sense to pay a fee everytime you ask one.
>
> Does any of this makes any sense to you ?
>
> Thanks,
>
> Clément
>
--
Clément ELBAZ
06. 09. 55. 78. 41
clem.ds at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140109/e419fe72/attachment.html>

2023-06-07 15:12:01 UTC

- reply

📅 Original date posted:2014-01-08
📝 Original message:Hello all,
I'm designing a program that needs some metrics computed from the Bitcoin
block chain (some address balances, or the occurrence or not of a specific
transaction). The kind of infos you get from http://blockchain.info/,
provided you trust this website (my program do not).
My program should run on lightweight/embedded hardware. The execution
environment provides access to the Bitcoin network but not enough resources
to set up a trusted node along with my program. Also, my program trusts the
global Bitcoin network but no individual node.
I would need a way to ask an untrusted Bitcoin node to compute some 'metric
request' on my behalf and having the result of that metric request
validated by the network.
Is there any available or work-in-progress projects that would come close
to this need ? Or should I do it myself ? :-)
Thank you all,
Clément Elbaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140108/2a00a136/attachment.html>

2023-06-07 15:12:01 UTC

- reply

📅 Original date posted:2014-01-08
📝 Original message:Some more thoughts :
If no such project exist yet, I thought it could work with an alternate,
small and fixed-length 'metric request block chain' of some sort.
It would temporarily stores structures defined as [metric request | current
block number when request was made | hash of the response] instead of
financial transactions.
These structures are verifiable so it could work the same way as a regular
financial blochchain.
It should not be part of the main Bitcoin protocol but could be a plugin
interacting with the data managed by the fullnode bitcoin software.
Also, metrics requests can be expensive to compute and validate, so it
would make sense to pay a fee everytime you ask one.
Does any of this makes any sense to you ?
Thanks,
Clément
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140108/71676559/attachment.html>