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 less fungible coins. This is why we recommend 6 confirmations for important payments. On Fri, Nov 28, 2014 at 3:18 AM, Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27 November 2014 18:46:23 GMT-05:00, Gregory Maxwell gmaxw...@gmail.com wrote: snip 100% accurate commentary from gmaxwell The things you're suggesting were all carefully designed out of the proposal, perhaps the BIP text needs some more clarification to make this more clear. It does; it is still a draft. That said I think writing up some actual working examples, in code, of CHECKLOCKTIMEVERIFY using protocols is a bigger priority. Micropayment channels comes to mind, as well as a greenaddress-style wallet. When I get a chance I'm going to rebase the initial implementation and add to it a command-line-flag to verify CHECKLOCKTIMEVERIFY as an IsStandard() rule for testing purposes. -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQFQBAEBCAA6BQJUd+luMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8 cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhWmcB/0UK030Q6TSpi95x0Gh hGYaSAInUWpbZzZtP+1AFrGDGRdGo0glFFf8xggI+U5kuc0woPYrn/VEGcprPhvs KQFZrirXVr7Q09TVlHiPDen5v3Y7xwL5kQDUrBPP71Pe3R2o6IbfdwxsZ8+yYso8 hY6WQmImQpKJd4gEd76w1QrF8Btl1Jz/PGh4EE3GSPGlflvBwA6igSiRoD/czb1x 63y4AsPEil2hrmIjTZHqwnl40BqnmZ8qpNLWeIEjE++pbkxLTjvUcPy03/wtTWZA 5dCGeY5WavgZsPazhSdaTtM5/7wPSQQ0PDXNHdHgmewkvbyBpy78orV/3bEG+xFz 2SWi =4OmI -END PGP SIGNATURE- -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
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 btcd...@gmail.com 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 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-10-transaction-on-the-counterparty-network/ [2] http://blockscan.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 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. Flavien On Mon, Nov 17, 2014 at 10:35 AM, Pieter Wuille pieter.wui...@gmail.com wrote: On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner etothe...@gmail.com wrote: On 11/16/2014 02:04 PM, Jorge Timón wrote: I remember people asking in #bitcoin-dev Does anyone know any use case for greater sizes OP_RETURNs? and me answering I do not know of any use cases that require bigger sizes. For reference, there was a brief time where I was irritated that the size had been reduced to 40 bytes, because I had an application where I wanted to put ECDSA in signatures in the OP_RETURN, and you're going to need at least 64 bytes for that. Unfortunately I can't remember now what that application was, so it's difficult for me to argue for it. But I don't think that's an unreasonable use case: sending a payment with a signature, essentially all timestamped in the blockchain. You can still send the signature out of band (for example using the payment protocol), and just have the transaction commit to a hash of that signature (or message in general), either using an OP_RETURN output to store the hash, or using the pay-to-contract scheme that Jorge mentioned above. That has exactly the same timestamping properties. My main concern with OP_RETURN is that it seems to encourage people to use the blockchain as a convenient transport channel, rather than just for data that the world needs to see to validate it. I'd rather encourage solutions that don't require additional data there, which in many cases (but not all) is perfectly possible. -- Pieter -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[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 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 -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 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 -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[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 -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 1 October 2014 17:55:36 GMT-07:00, Luke Dashjr l...@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 l...@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=154622311iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=154622311iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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, 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 t...@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 jgar...@bitpay.com wrote: On Sat, May 3, 2014 at 2:04 PM, Flavien Charlon flavien.char...@coinprism.com wrote: 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? The carried data must all be contained within one pushdata. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[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.
0100015594a8c1f84b926e84d70c3a3d5e517e0c12dc07cb1a774b587121fef08f91b86b48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f0210c169b85074429b1b1c2f32e19509d7ed19f7804ab7212bd183a012102add59262e234c0045d1f6a3d40a144b47ea0b4214916f55fb6029a079cc0b3cb0358021976a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac0a6a054f4101000102753d60861976a9140f763005e063382f8f4138f75cdc64d14f8ec16f88ac
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:48304502202f534407f6dee4d8932ec22491cbc15a2d31af2bade4e8d417e4b1955de57f5902210086e2f0210c169b85074429b1b1c2f32e19509d7ed19f7804ab7212bd183a012102add59262e234c0045d1f6a3d40a144b47ea0b4214916f55fb6029a079cc0b3cb
}
],
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
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
I have updated the spechttps://github.com/Flavien/colored-coins-protocol/blob/master/specification.mediawiki . 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 have per transaction is limited by OP_RETURN's 40 bytes. We use a compact format (LEB128http://en.wikipedia.org/wiki/LEB128) for the asset quantity of each output to mitigate that. Assuming you're transferring small amounts of colored coins, you could have up to about 30 colored ouputs. It should work for a decentralized exchange (you only really need 2 or 3 colored outputs). Applications like sending dividends in colored coins however may require splitting into several smaller transactions, but I believe that's an acceptable limitation. On Thu, Apr 10, 2014 at 6:24 PM, Alex Mizrahi alex.mizr...@gmail.comwrote: At this point, I don't think what you are doing is even colored coins anymore. You might want to look into Counterparty or Mastercoin. Nope, it's still colored coins. The difference between colored coin model and Mastercoin model is that colored coins are linked to transaction outputs, while Mastercoin has a notion of address balances. The implications of this is that in colored coin model explicit dependencies allow us to rely on SPV. (Assuming that one can fetch the dependency graph to link txout in question to genesis.) While it is not the case with Mastercoin. While it's pretty far from the original colored coins model, what Flavien have described is identical to it in majority of aspects. This is an interesting approach, but OP_RETURN size limitations can be a significant problem for some kinds of applications. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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 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.mizr...@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
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 m...@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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_APR___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
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 jti...@monetize.io wrote: On 4/7/14, Flavien Charlon flavien.char...@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. -- 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_APR___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
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 jti...@monetize.io wrote: On 4/7/14, Flavien Charlon flavien.char...@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? -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
