<unnamed>

Public Key

npub1k4rlc2efxduexgkt7dd9fjva0wrayv88mwewftnzmurleznnx9ssssfa2f

Profile Code

nprofile1qqst23lu9v5nx7vnyt9lxkj5exwhhp7jxrnahvhy4e3d7plu3fenzcgpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0upchv2

Publishing to

relay.primal.net

relay.damus.io

Last Notes

2023-06-07 17:27:28 CEST

- 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 17:26:38 CEST

- 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 17:26:07 CEST

- 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 17:20:53 CEST

- 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 17:17:29 CEST

- reply

📅 Original date posted:2014-04-10
📝 Original message:Thanks for the valuable feedback. I see there is a strong concern with
requiring a large BTC capital for issuing coloring coins, so I am now in
the process of modifying the specification to address that. I will post an
update when this is finished.
By the way, padding doesn't solve the issue entirely (issuing 10 billion
shares sill takes you 100 BTC, even with padding and 1 satoshi = 1 share),
so I am going for the solution where the asset quantity of every output is
explicitly encoded in the OP_RETURN output. That way, whether you are
issuing 1 share or 100 trillions, you never need to pay more than 540
satoshis.
On Mon, Apr 7, 2014 at 8:58 PM, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
> This is beyond ridiculous...
>
> Color kernel which works with padding is still quite simple. I think we
> have extra 10-50 lines of code to handle padding in coloredcoinlib.
> Essentially we have a couple of lines like this :
>
> value_wop = tx.outputs[oi].value - padding
>
> (value_wop means "value without padding").
> And then we have like 10 lines of code which selects padding for a
> transaction.
>
> That's not a lot of extra complexity. And it solves the problem once and
> for all.
>
> What you propose instead: "a different colored coin representing 10
> shares, and another one representing 100 shares (like the different
> denominations of dollar bills)" is much more complex, and it won't work:
>
> Suppose you have $100 coin, as a single coin.
> How do you send $54.23?
> That's simply impossible.
>
> So you'd rather push complexity to higher levels (and create inconvenience
> for end users, as you admitted yourself) than add 10-50 lines of code to
> color kernel?
> I just do not understand this.
>
> But I'm not going to argue. I already wrote everything which I could write
> on this topic.
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> 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/20140410/06ce07c4/attachment.html>

2023-06-07 17:17:28 CEST

- reply

📅 Original date posted:2014-04-07
📝 Original message:Ok, I guess I'm not using the proper terminology. It would be listed on the
"Asset" section of the company's balance sheet, is what I meant.
On Mon, Apr 7, 2014 at 4:06 PM, Mark Friedenbach <mark at monetize.io> wrote:
> Flavien, capital is wealth or resources available for the stated purpose
> of the company. These bitcoins represent nothing more than a speculative
> floor owned by the investors, not the company.
>
> On 04/07/2014 07:00 AM, Flavien Charlon wrote:
> > 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
> > <mailto:jtimon at monetize.io>> wrote:
> >
> > On 4/7/14, Flavien Charlon <flavien.charlon at coinprism.com
> > <mailto: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/bffc7bc8/attachment.html>

2023-06-07 17:17:28 CEST

- reply

📅 Original date posted:2014-04-07
📝 Original message:An IOU written in a gold plate sure makes no sense. I see what you are
saying, the inconvenience comes from the fact that the buyer has to buy
some amount of BTC at the same time as he buys a share.
That's why I was making the point that you could have a colored coin
representing a single share, a different colored coin representing 10
shares, and another one representing 100 shares (like the different
denominations of dollar bills). Assuming you have a proper application
layer/UI that can hide this from the user, the need for padding is greatly
reduced. My opinion is that the protocol should do the minimum required and
remain as simple as possible. If a proper UI can work around this, then it
might not be worth complicating the protocol for this. Also, the dust rule
may disappear all together one day (it's already been slashed heavily to
540 satoshis), at which point we'll be left with a useless padding
parameter. It's easier to add something when you need it than to remove it.
But I am posting here to see how people feel about this, and I see you are
on the opinion that satoshi_value and color_value should have a degree of
freedom between each other. Thanks for the feedback.
On Mon, Apr 7, 2014 at 7:23 PM, Jorge Timón <jtimon at monetize.io> wrote:
> On 4/7/14, Flavien Charlon <flavien.charlon at coinprism.com> wrote:
> > Ok, I guess I'm not using the proper terminology. It would be listed on
> the
> > "Asset" section of the company's balance sheet, is what I meant.
>
> No, it's an asset for the owner of the share, not the company, just
> like the gold plates are not assets for the company when someone else
> holds them.
> What you're doing is getting less capital for the company due to the
> money that is going to pay the gold costs.
> Are you rising capital or selling gold?
> It doesn't make sense to do both at once.
> You need money, why would you spend money on gold before asking for
> other people's money to build your company?
> Investors will appreciate the convenience of being able to buy shares
> of your company and gold separately (or not buy gold at all).
>
> It may even be more clear for other use cases different than stocks.
> Does an IOU written in a gold plate make sense to you?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140407/d60b3540/attachment.html>

2023-06-07 17:17:27 CEST

- reply

📅 Original date posted:2014-04-07
📝 Original message:Thanks for the feedback Mark.
> (1) there is absolutely no reason to include asset tagging information if
it is not validated
Sure, there is a good reason to include it in the blockchain: so that
clients don't need external information to recognize colored coins. Also,
I'm not sure what you mean by "not validated", in that proposal, the tagged
transaction is the authoritative source of information.
> that just bloats the block chain
9 bytes is much less than what Mastercoin and counterparty are doing
(certainly under the 40 bytes allowed).
> Have you seen the padded order-based coloring scheme worked out here?
Yes I have seen it and find the padding quite clumsy and unintuitive. A
more general solution is the one I described in my original post, where the
color value is entirely separate from the satoshi value, and encoded
separately: if you have to have an additional "padding" value to calculate
color_value = satoshi_value - padding, you might as well have color_value
directly, independently from satoshi_value. But I don't even think it is
necessary:
> (2) And needing a capital of 54 btc for a million shares is totally
unacceptable.
An easy workaround is to have various scales, the same way you have $1
bills, $5 bills an $10 bills. I don't see that as a big problem. That way
the protocol is more lightweight and simple.
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.
Best,
Flavien
On Mon, Apr 7, 2014 at 12:23 AM, Mark Friedenbach <mark at monetize.io> wrote:
> On 04/06/2014 01:59 PM, Flavien Charlon wrote:
> > Do you think this is the right approach?
>
> No, I'm afraid it has significant flaws. The two chief flaws are (1)
> there is absolutely no reason to include asset tagging information if it
> is not validated - that just bloats the block chain, and (2) you
> shouldn't be using fixed increments for share sizes either. It's not
> future-proof as the minimum output size changes based on the minimum fee
> (currently 540 satoshis, not 5,400, and it will float in the near
> future). And needing a capital of 54 btc for a million shares is totally
> unacceptable.
>
> Flavien, I know that I've seen you on the Bitcoin-X mailing list, where
> these issues have been mostly worked out:
>
> https://groups.google.com/forum/#!forum/bitcoinx
>
> Have you seen the padded order-based coloring scheme worked out here?
>
> https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro
>
> Kind regards,
> Mark Friedenbach
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20140407/ce33a33f/attachment.html>

2023-06-07 17:17:27 CEST

- 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 17:17:26 CEST

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