Re: [Bitcoin-development] deterministic transaction expiration

> 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

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

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 wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > > On 1 October 2014 17:55:36 GMT-07:00,

[Bitcoin-development] About watch-only addresses

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 -

Re: [Bitcoin-development] About watch-only addresses

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.char...@coinprism.com> wrote: > Hi, > > What is the status of watch-only addresses in Bitcoin Core? Is it merged > in master and usable? Is ther

[Bitcoin-development] Increasing the OP_RETURN maximum payload size

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

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

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

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

nsume less space in the blockchain if they used OP_RETURN). On Tue, Nov 18, 2014 at 5:47 PM, Btc Drak wrote: > On Mon, Nov 17, 2014 at 11:43 AM, Flavien Charlon < > flavien.char...@coinprism.com> wrote: > >> > My main concern with OP_RETURN is that it seems to encourage

Re: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...

> This breaks existing invariants and would make the coins potentially less fungible because they wouldn't be reorg safe. I'm not sure coins are ever reorg safe. All it takes is a double spend in the history of your coins for them to become invalid after a reorg. Because of that, there are already

[Bitcoin-development] Feedback request: colored coins protocol

Hi, I am the lead developer of Coinprism , 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 fo

Re: [Bitcoin-development] Feedback request: colored coins protocol

pital 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 wrote: > On 04/06/2014 01:59 PM, Flavien Charlon wrote: > > Do you think

Re: [Bitcoin-development] Feedback request: colored coins protocol

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 wrote: > On 4/7/14, Flavien Charlon wrote: > > Also those 54 BTC (actually 5.4 BTC if the dust is now 540 satoshis) > become > >

Re: [Bitcoin-development] Feedback request: colored coins protocol

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

Re: [Bitcoin-development] Feedback request: colored coins protocol

nks for the feedback. On Mon, Apr 7, 2014 at 7:23 PM, Jorge Timón wrote: > On 4/7/14, Flavien Charlon 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.

Re: [Bitcoin-development] Feedback request: colored coins protocol

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 entir

Re: [Bitcoin-development] Feedback request: colored coins protocol

I have updated the spec . > This is an interesting approach, but OP_RETURN size limitations can be a significant problem for some kinds of applications. This is correct, the number of colored outputs you can ha

[Bitcoin-development] Bug with handing of OP_RETURN?

Can someone enlighten me on why the following transaction is being rejected by Bitcoind 0.9.1 with error code -22 on Mainnet. 0100015594a8c1f84b926e84d70c3a3d5e517e0c12dc07cb1a774b587121fef08f91b86b48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f021

Re: [Bitcoin-development] Bug with handing of OP_RETURN?

Thanks, that makes sense, just wanted to make sure this what the problem was. On Sun, May 4, 2014 at 6:15 AM, Jeff Garzik wrote: > On Sat, May 3, 2014 at 2:04 PM, Flavien Charlon > wrote: > > Outputs are above dust, inputs are not spent. OP_RETURN is supposed to be > > sta