Flavien Charlon [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-04-06 to 2014-11-28
💬 Posted a total of 17 messages
📚 Participated in the following categories: Bitcoin-development, BIP draft
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:27:31

- reply

📅 Original date posted:2014-11-18
📝 Original message:>
> While I am not opposing the proposal, I am not sure about your statistics
> because while Counterparty is not currently using OP_RETURN encoding, you
> should factor in the number of CP transactions that would have been
> OP_RETURNs if they had been permitted (100,000 since inception according
> their blog[1] with monthly charts at their block explorer[2]).
Sure, but even if they are not permitted to store their data in OP_RETURN,
they will still store it in the blockchain in bare multisig outputs, so
it's not contributing to an overhead (in fact, it would consume less space
in the blockchain if they used OP_RETURN).
On Tue, Nov 18, 2014 at 5:47 PM, Btc Drak <btcdrak at gmail.com> wrote:
> On Mon, Nov 17, 2014 at 11:43 AM, Flavien Charlon <
> flavien.charlon at coinprism.com> wrote:
>
>> > My main concern with OP_RETURN is that it seems to encourage people to
>> use the blockchain as a convenient transport channel
>>
>> The number one user of the blockchain as a storage and transport
>> mechanism is Counterparty, and limiting OP_RETURN to 40 bytes didn't
>> prevent them from doing so. In fact they use multi-sig outputs which is
>> worse than OP_RETURN since it's not always prunable, and yet let them store
>> much more than 40 bytes.
>>
>> For Open Assets <https://github.com/OpenAssets/open-assets-protocol>, we
>> need to store a URL in the OP_RETURN output (with optionally a hash) plus
>> some bytes of overhead. 40 bytes comes really short for that. The benefit
>> of having a URL in there is that any storage mechanism can be used (Web,
>> FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to
>> hardcode the storing mechanism in the protocol (and even then, a hash is
>> not enough to address a HTTP or FTP resource). Storing only a hash is fine
>> for the most basic timestamping application, but it's hardly enough to
>> build something interesting.
>>
>> I've counted the number of OP_RETURN outputs in the blockchain for the
>> month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659
>> blocks. Assuming they were all 40 bytes (the average is probably less than
>> half of that), that means an increase of 14.37 bytes per block. Considering
>> a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN
>> data in average.
>>
>> Increasing to 80 bytes will have a negligible impact on bandwidth and
>> storage requirements, while being extremely useful for many use cases where
>> a hash only is not enough.
>>
>
> While I am not opposing the proposal, I am not sure about your statistics
> because while Counterparty is not currently using OP_RETURN encoding, you
> should factor in the number of CP transactions that would have been
> OP_RETURNs if they had been permitted (100,000 since inception according
> their blog[1] with monthly charts at their block explorer[2]).
>
> Refs:
> [1]
> http://counterparty.io/news/celebrating-100000-transaction-on-the-counterparty-network/
> [2] http://blockscan.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141119/3e9b16f5/attachment.html>

2023-06-07 15:27:28

- reply

📅 Original date posted:2014-11-16
📝 Original message:Hi,
The data that can be embedded as part of an OP_RETURN output is currently
limited to 40 bytes. It was initially supposed to be 80 bytes, but got
reduced to 40 before the 0.9 release to err on the side of caution.
After 9 months, it seems OP_RETURN did not lead to a blockchain
catastrophe, so I think it might be time to discuss increasing the limit.
There are a number of proposals:
1. Allow two OP_RETURN outputs per transaction (PR
<https://github.com/bitcoin/bitcoin/pull/5075>)
2. Increase the default maximum payload size from 40 bytes to 80 bytes (
PR <https://github.com/bitcoin/bitcoin/pull/5286>)
Note that the maximum can be configured already through the
'datacarriersize' option - this is just changing the default.
3. Make the maximum OP_RETURN payload size proportional to the number of
outputs of the transaction
4. A combination of the above
3 sounds the most interesting, and 2 would be the second best.
1 is also good to have as long as the "space budget" is shared between the
two outputs.
Can we discuss this and agree on a plan?
Thanks,
Flavien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141116/91741296/attachment.html>

2023-06-07 15:26:38

- reply

📅 Original date posted:2014-10-17
📝 Original message:Hi,
What is the status of watch-only addresses in Bitcoin Core? Is it merged in
master and usable? Is there documentation on how to add a watch-only
address through RPC.
Also, I believe that is going towards the 0.10 release, is there a
rough ETA for a release candidate?
Thanks
Flavien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141017/3fced468/attachment.html>

2023-06-07 15:26:38

- reply

📅 Original date posted:2014-10-18
📝 Original message:Also, I was wondering if there were nightly builds I could try this from?
On Fri, Oct 17, 2014 at 9:36 PM, Flavien Charlon <
flavien.charlon at coinprism.com> wrote:
> Hi,
>
> What is the status of watch-only addresses in Bitcoin Core? Is it merged
> in master and usable? Is there documentation on how to add a watch-only
> address through RPC.
>
> Also, I believe that is going towards the 0.10 release, is there a
> rough ETA for a release candidate?
>
> Thanks
> Flavien
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141018/7584839b/attachment.html>

2023-06-07 15:26:07

- reply

📅 Original date posted:2014-10-02
📝 Original message:Very good, I like the proposal.
A question I have: can it be used to do the opposite, i.e. build a script
that can only be spent up until block X?
On Thu, Oct 2, 2014 at 2:09 AM, Peter Todd <pete at petertodd.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr <luke at dashjr.org> wrote:
> >On Thursday, October 02, 2014 12:05:15 AM Peter Todd wrote:
> >> On 1 October 2014 11:23:55 GMT-07:00, Luke Dashjr <luke at dashjr.org>
> >wrote:
> >> >Thoughts on some way to have the stack item be incremented by the
> >> >height at
> >> >which the scriptPubKey was in a block?
> >>
> >> Better to create a GET-TXIN-BLOCK-(TIME/HEIGHT)-EQUALVERIFY operator.
> >> scriptPubKey would be:
> >> GET-TXIN-BLOCKHEIGHT-EQUALVERIFY
> >> (fails unless top stack item is equal to the txin block height)
> >> <delta height> ADD
> >> (top stack item is now txin height + delta height)
> >> CHECKLOCKTIMEVERIFY
> >
> >This sounds do-able, although it doesn't address using timestamps.
>
> For timestamps replace "height" with "time" in the above example; the
> minimum block time rule will prevent gaming it.
>
>
> >> You'd want these sacrifices to unlock years into the future to
> >thoroughly
> >> exceed any reasonable business cycle; that's so far into the future
> >that
> >> miners are almost certain to just mine them and collect the fees.
> >
> >For many use cases, short maturity periods are just as appropriate IMO.
>
> Very easy to incentivise mining centralisation with short maturities. I
> personally think just destroying coins is better, but it doesn't sit well
> with people so this is the next best thing.
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.1.1
>
> iQFQBAEBCAA6BQJULKWsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
> cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhcg8CACueZNGfWaZR+xyG9/o
> JwDBCnqOtwr6Bnosg3vNcRIDUnmsh+Qkk5dk2JpqYNYw7C3duhlwHshgsGOFkHEV
> f5RHDwkzGLJDLXrBwxxcIDdm3cJL8UVpQzJ7dD7aSnfj7MU/0aru3HaIU2ZfymUb
> 63jhul6FGbXH3K6p3bOoNrfIrCCGOv8jOIzeAgxNPydk8MVPgRhlYLAKBJxu8nMr
> 1oJGeaKVSGSPSrRdgS8tI4uOs0F4Q49APrLPGxGTERlATmWrr+asHGJTIxsB2IEm
> vrNgVRpkaN4Of9k96qzD9ReKfBfqm0WQKLolcXCVqGpdoHcvXh2AeWdjB/EFTyOq
> SOgO
> =WybM
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20141002/d08a3134/attachment.html>

2023-06-07 15:24:41

- reply

📅 Original date posted:2014-08-05
📝 Original message:> It would make more sense to introduce a new script opcode that pushes the
current block height onto the operand stack. Then you could implement
arbitrary logic about which blocks the transaction can be valid in. This
would require that the client revalidate all transactions in its mempool
(really, only those making use of this opcode) whenever the chain tip
changes.
I have to say I like this idea, this would allow someone to prove they
can't spend funds before a given date, and vice versa, prove that the funds
can't ever be spent after a given date (and this is provably prunable,
isn't it?). Of course, there are some risks associated with that, but
nobody is forced to use it.
> flooding the network with unrelated high fee transactions
> in order to push a transaction out to where it can never be mined at
> all.
This becomes increasingly expensive as the deadline is further away, so not
very hard to mitigate.
On Sat, Aug 2, 2014 at 1:36 AM, Tom Harding <tomh at thinlink.com> wrote:
> On 7/31/2014 5:58 PM, Kaz Wesley wrote:
> > 1. start setting nLockTime to the current height by default in newly
> > created transactions (or slightly below the current height, for
> > reorg-friendliness)
>
> Reorg-frendliness is the opposite of the rationale behind #2340, which
> proposes setting nLockTime at current-height + 1 to prevent
> "fee-sniping" reorgs...
>
>
> > 2. once users have had some time to upgrade to clients that set
> > nLockTime, start discouraging transactions without nLockTime --
> > possibly with a slightly higher fee required for relay
> > 3. start rate-limiting relay of transactions without an nLockTime
> > (maybe this alone could be used to achieve [2])
> > 4. add a new IsStandard rule rejecting transactions with an nLockTime
> > more than N blocks behind the current tip (for some fixed value N, to
> > be determined)
> >
>
> One way to proceed is implement #3753 (mempool janitor) in such a way
> that transactions with nLockTime are allowed to live a bit longer in the
> mempool (say 500 blocks) than those without (72 hours). In other words,
> as a first step, just actually start expiring things from the mempool in
> bitcoin core, and leave any relay fee adjustments or rate limiting for
> later. The isStandard change would be a good complement to #3753, to
> avoid relaying a tx that will soon expire by the nLockTime rule anyway.
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> 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/20140805/6b077ada/attachment.html>

2023-06-07 15:20:53

- reply

📅 Original date posted:2014-05-03
📝 Original message:Can someone enlighten me on why the following transaction is being rejected
by Bitcoind 0.9.1 with error code -22 on Mainnet.
01000000015594a8c1f84b926e84d70c3a3d5e517e0c12dc07cb1a774b587121fef08f91b8000000006b48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f0210c16ffff9b85074429b1b1c2f32e19509d7ed19f7804ab7212bd183a012102add59262e234c0045d1f6a3d40a144b47ea0b4214916f55fb6029a079cc0b3cbffffffff0358020000000000001976a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac00000000000000000a6a054f4101000102753d60860000000000001976a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac00000000
Debug.log shows the following:
ERROR: AcceptToMemoryPool : nonstandard transaction: scriptpubkey
Here is the decoded transaction:
{
> "lock_time":0,
> "inputs":[
> {
> "prev_out":{
> "index":0,
>
> "hash":"b8918ff0fe2171584b771acb07dc120c7e515e3d3a0cd7846e924bf8c1a89455"
> },
>
> "script":"48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f0210c16ffff9b85074429b1b1c2f32e19509d7ed19f7804ab7212bd183a012102add59262e234c0045d1f6a3d40a144b47ea0b4214916f55fb6029a079cc0b3cb"
> }
> ],
> "vout_sz":3,
>
> "hash":"44130e812fa15f411c6accb739082eb81ecf074470cefb8e617ecf105690f6e1",
> "vin_sz":1,
> "out":[
> {
> "address":"12QkihKUyE1hAkv7wmaMj6V3QiN8FfMvpv",
> "script_string":"OP_DUP OP_HASH160
> 0f763005e063382f8f4138f75cdc64d14f8ec16f OP_EQUALVERIFY OP_CHECKSIG",
> "value":600,
> "script":"76a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac"
> },
> {
> "script_string":"OP_RETURN 4f41010001 753d",
> "value":0,
> "script":"6a054f4101000102753d"
> },
> {
> "address":"12QkihKUyE1hAkv7wmaMj6V3QiN8FfMvpv",
> "script_string":"OP_DUP OP_HASH160
> 0f763005e063382f8f4138f75cdc64d14f8ec16f OP_EQUALVERIFY OP_CHECKSIG",
> "value":34400,
> "script":"76a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac"
> }
> ],
> "size":245,
> "version":1
> }
>
Outputs are above dust, inputs are not spent. OP_RETURN is supposed to be
standard in 0.9.1 and the data is well below 40 bytes, so why is this being
rejected?
Thanks,
Flavien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140503/e33b8a5a/attachment.html>

2023-06-07 15:17:27

- reply

📅 Original date posted:2014-04-07
📝 Original message:Jorge, they'd have to be. Otherwise, assuming the price of the share goes
low enough, you could buy a share of the company, melt the gold plate, and
sell it for a profit. If the gold is part of the capital of the company,
the cheapest a share can be is the price of the gold on which the stock
certificate is printed.
This is why I think the importance of padding with colored coins is
overblown.
On Mon, Apr 7, 2014 at 1:12 PM, Jorge Timón <jtimon at monetize.io> wrote:
> On 4/7/14, Flavien Charlon <flavien.charlon at coinprism.com> wrote:
> > Also those 54 BTC (actually 5.4 BTC if the dust is now 540 satoshis)
> become
> > part of the capital of the company, and can always be recovered by
> > uncoloring the shares. It's an investment, not an expense, so I think it
> is
> > acceptable.
>
> This doesn't make much sense to me.
> If you print shares on gold plates instead of paper, is that gold
> "part of the capital of the company"? I don't think so.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/9186845a/attachment.html>

2023-06-07 15:17:26

- reply

📅 Original date posted:2014-04-06
📝 Original message:Hi,
I am the lead developer of Coinprism <https://www.coinprism.com/>, the new
colored coins web wallet. After some discussions with the other people
involved with colored coins, I wrote a specification document describing
the colored coins protocol that we are using in coinprism.
I am looking for feedback/discussions regarding the protocol before we move
from TestNet to MainNet. The document is here:
https://github.com/Flavien/colored-coins-protocol/blob/master/specification.mediawiki
.
The colored coin protocol is layered on top of the existing Bitcoin
protocol and requires no modification of the existing protocol, so it can
be used today. This means that SPV is not as efficient, as the client needs
to backtrack up to the issuing transaction to find the color of an output,
but that is something we can live with.
The protocol marks transactions either as issuance or transfer transactions
by using an OP_RETURN output with a 9 bytes marker. The protocol uses the
value of an output as the colored value. So if an output has 1 BTC and is
colored with color A, that means we have 1 BTC colored with color A.
An alternative would have been to completely disconnect the colored value
and the real BTC value. The colored value of each output would be encoded
in an OP_RETURN output. Someone who wants to send 1000 colored coins would
craft a transaction with an output with the smallest possible amount of BTC
(5,400 satoshis) and indicate in the OP_RETURN that they are sending 1000
colored coins.
The two reasons why we haven't chosen that approach is that first, this
only works with a limited number of outputs given that we have only 40
bytes. And second, this could lead to people spamming the network with very
small outputs (but containing an arbitrary number of colored coins).
On the other hand, with the approach we're using (colored value = actual
value of the output), the 5,400 satoshis rule means that the smallest unit
of colored coin you can send is 5,400 satoshis.
If you want to issue 1 million shares, while still being able to trade each
share individually, you'd have to set 1 share = 5,400 satoshis, and you
would need a capital of 54 BTC for issuing a million shares. It's not a big
problem in itself, but still a slight inconvenience.
Do you think this is the right approach?
Feel free to reply with any feedback regarding the protocol.
Thanks,
Flavien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140406/41d33754/attachment.html>