BitcoinTangibleTrust



Offline



Activity: 111

Merit: 10



Digitizing Valuable Hard Assets with Crypto







MemberActivity: 111Merit: 10Digitizing Valuable Hard Assets with Crypto Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official March 28, 2014, 08:41:15 PM #6384



Product and Service Updates March 28, 2014



Purchasing 1/2 Ounze of Gold with BitcoinTangibleTrust with Counterparty community member, led_cd:

Led_cd has confirmed his desired gold he wished to purchase: 1/2 Ounce of Gold American Eagle here:

Listed Price: 1.4090 BTC

Our Price: 1.4 BTC



Agora has setup a BTC Address for BTT customer payments. Once led_cd has verified and made payment, he will receive his new Digital Gold Coin on Counterparty.



Agora has special instructions to route led_cd's physical gold directly into custody and deliver proof of purchase to BitcoinTangibleTrust. DiamondState Depository is ready to receive the gold and confirm custody.



led_cd has a new Asset on Counterparty that will be sent to his address:

You can see the asset detail here:

1 Unit for 1 Coin

Non-divisible

Callabe True

NOTE: We couldn't issue 0.5 denomination of the coin AND make it non-divisible so we went with 1. However, I wonder whether we should normalize our issuances to the same measure for precious metals, by weight, or whether we should stick to units purchased, which is our current approach. I'd welcome any community thoughts on how we might address this issue.



BitcoinTangibleTrust makes the news

We were surprised to learn that we were in the news today.

http://www.bloomberg.com/news/2014-03-28/bitcoin-2-0-shows-technology-evolving-beyond-use-as-money.html

Special thanks Anotheranonlol for catching the article. We've been a little buried here structuring our purchase and custody process.



Thank you Counterparty Devs and the Counterparty Community,

Bitcoin Tangible Trust Team

Cross Posted to Counterparty Forums:

Led_cd has confirmed his desired gold he wished to purchase: 1/2 Ounce of Gold American Eagle here: https://agoracommodities.com/product/12-oz-gold-american-eagle/ Listed Price: 1.4090 BTCOur Price: 1.4 BTCAgora has setup a BTC Address for BTT customer payments. Once led_cd has verified and made payment, he will receive his new Digital Gold Coin on Counterparty.Agora has special instructions to route led_cd's physical gold directly into custody and deliver proof of purchase to BitcoinTangibleTrust. DiamondState Depository is ready to receive the gold and confirm custody.You can see the asset detail here: http://blockscan.com/assetinfo.aspx?q=GLDAGOAAAAAAA We couldn't issue 0.5 denomination of the coin AND make it non-divisible so we went with 1. However, I wonder whether we should normalize our issuances to the same measure for precious metals, by weight, or whether we should stick to units purchased, which is our current approach. I'd welcome any community thoughts on how we might address this issue.We were surprised to learn that we were in the news today.Special thanks Anotheranonlol for catching the article. We've been a little buried here structuring our purchase and custody process.Thank you Counterparty Devs and the Counterparty Community,Bitcoin Tangible Trust TeamCross Posted to Counterparty Forums: https://forums.counterparty.co/index.php/topic,203.0.html

Digitizing Valuable Hard Assets with Crypto Digital TangibleDigitizing Valuable Hard Assets with Crypto http://www.digitaltangibletrust.com

Peter Todd



Offline



Activity: 1106

Merit: 1045







LegendaryActivity: 1106Merit: 1045 Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official March 28, 2014, 08:50:35 PM #6385 Quote from: porqupine on March 28, 2014, 07:50:10 PM Quote from: Luke-Jr on March 28, 2014, 07:41:00 PM Quote from: ripplebtc on March 27, 2014, 08:20:00 AM

https://www.counterparty.co/pay-to-pubkeyhash-functionality-added/

Great news! Pay-to-PubKeyHash Functionality Added

Great news! Filter added to block this crap in less than 5 minutes, and 1 line of code.

Great instead of developers responsibly engaged towards finding a solution - you're promoting cat and mouse.



You realize you're also saying fuck it to net-neutrality? And trying to take into private hands what kind of transactions people should and shouldn't make on the Blockchain.

Great instead of developers responsibly engaged towards finding a solution - you're promoting cat and mouse.You realize you're also saying fuck it to net-neutrality? And trying to take into private hands what kind of transactions people should and shouldn't make on the Blockchain.

Heh, well, I had an interesting discussion about this stuff with one of the core devs, and there's actually kind of a nice advantage to Counterparty and similar moving to a system where careful steganography and similar measures are being taken to keep the system unblocked: if someone does do the "fill the chain with child porn" legal attack on Bitcoin the community can argue that they certainly didn't support it in any way. It also goes back to things like trying to ban or discourage address reuse: if your protocol can be censored, changing it to be harder to censor tends to be actually good for the ecosystem as a whole.



An interesting thing to do might be to change Bitcoin to validate that 33 byte PUSHDATA's are valid pubkeys in the IsStandard() rules. The easiest way to co-erce arbitrary data to look like a pubkey is via something like Mastercoin's encoding scheme, and that has the nice property of being easiest to implement with steganography that hides the data and gives everyone in the ecosystem good plausible deniability.



Anyway, I'm gonna write more about this in the coming weeks as a semi-formal paper, as well as talk about when you can get away with the lesser security of hash-linked side-chain schemes. Some best practices libraries implementing both would be useful for everyone in this ecosystem.





Also, congrats on BitcoinTangibleTrust for doing something with this tech. Heh, well, I had an interesting discussion about this stuff with one of the core devs, and there's actually kind of a nice advantage to Counterparty and similar moving to a system where careful steganography and similar measures are being taken to keep the system unblocked: if someone does do the "fill the chain with child porn" legal attack on Bitcoin the community can argue that they certainly didn't support it in any way. It also goes back to things like trying to ban or discourage address reuse: if your protocol can be censored, changing it to be harder to censor tends to be actually good for the ecosystem as a whole.An interesting thing to do might be to change Bitcoin to validate that 33 byte PUSHDATA's are valid pubkeys in the IsStandard() rules. The easiest way to co-erce arbitrary data to look like a pubkey is via something like Mastercoin's encoding scheme, and that has the nice property of being easiest to implement with steganography that hides the data and gives everyone in the ecosystem good plausible deniability.Anyway, I'm gonna write more about this in the coming weeks as a semi-formal paper, as well as talk about when you can get away with the lesser security of hash-linked side-chain schemes. Some best practices libraries implementing both would be useful for everyone in this ecosystem.Also, congrats on BitcoinTangibleTrust for doing something with this tech. BTC: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv PGP: 7FAB114267E4FA04

maaku



Offline



Activity: 905

Merit: 1003







LegendaryActivity: 905Merit: 1003 Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official March 28, 2014, 08:54:02 PM

Last edit: March 28, 2014, 09:19:54 PM by maaku #6386 Let me start with the good. There is a reason we (developer hat on) are generally up in arms about "abusive" data-on-blockchain proposals: it is because we see the potential of this tech! We know that issued assets and smart property contracts could grow to eclipse bitcoin traffic entirely. Some of us are even convinced this could happen quickly.



Why is this bad? Because despite bitcoin being in the process of going mainstream and getting all sorts of attention from everybody, everywhere, the number of full nodes is declining. As mentioned by others this is in large part due to the rise of SatoshiDice. Now I don't object to gambling services on bitcoin, nor do I know any other developers who do. What you do with your money is your business. The issue is that SD gave a trivial amount of satoshi's back to indicate a lost bet, which effectively was an uneconomical-to-spend data message similar in size to a class A Mastercoin transaction which Counterparty is sadly now adopting. That drain on the resources of the network from this extra data processing is causing people to turn off their full nodes and switch to SPV clients.



I don't want to cause undue fear and panic as with time and effort and education and innovation this situation is correctable. But if left to run its course this trend would mean the death of bitcoin. And parasitic[1] systems like mastercoin and counterparty make the situation worse. It's like adding bad weather, stormy seas, and sharks while we're treading water trying to find a solution.



Furthermore, it's simply not necessary. You can accomplish all of Counterparty's goals via off-chain solutions the same or similar security guarantees. There has been a lot of mis-information out there about this! That's why I pointed to the Freimarkets paper I co-authored with jtimon. It's not because I want to claim credit for the idea (it is as old as bitcoin), but to show there are worked out counter-proposals that could be implemented today.



We tried to make very clear from the beginning that OP_RETURN was never meant to be used. Enabling small data commitments is like cooperating with a mugger: losing your pride is preferable to losing your life. Likewise, if you insist on abusing the block chain than please at least don't do something so recklessly stupid and hurtful as a class A mastercoin transaction. Put a hash of the data in the block chain instead. OP_RETURN was only ever meant to contain a hash - 32 bytes.



But ultimately what you *should* be doing is running your own network and have a low-volume mechanism for transferring coins between the two. That helps bitcoin scale and gives you added capabilities like SPV support, pre-signed offers, and scripting extensions.



Our objection from the start has not been "we don't want to see this" but rather "we don't want to see it done in this particular way" because it externalizes costs and makes the situation worse than it already is.



[1] "Parasitic" has a well defined technical meaning and is not meant as a derogatory term here.



@Matt: Hi, it was good to meet you at CoinSummit!

If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP I'm an independent developer working on bitcoin-core , making my living off community donations.If you like my work, please consider donating yourself:

porqupine



Offline



Activity: 214

Merit: 100







Full MemberActivity: 214Merit: 100 Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official March 28, 2014, 09:17:52 PM #6387 Quote from: maaku on March 28, 2014, 08:54:02 PM Let me start with the good. There is a reason we (developer hat on) are generally up in arms about "abusive" data-on-blockchain proposals: it is because we see the potential of this tech! We know that issued assets and smart property contracts could grow to eclipse bitcoin traffic entirely. Some of us are even convinced this could happen quickly.



Why is this bad? Because despite bitcoin being in the process of going mainstream and getting all sorts of attention from everybody, everywhere, the number of full nodes is declining. As mentioned by others this is in large part due to the rise of SatoshiDice. Now I don't object to gambling services on bitcoin, nor do I know any other developers who do. What you do with your money is your business. The issue is that SD gave a trivial amount of satoshi's back to indicate a lost bet, which effectively was an uneconomical-to-spend data message similar in size to a class A Mastercoin transaction which Counterparty is sadly now adopting. That drain on the resources of the network from this extra data processing is causing people to turn off their full nodes and switch to SPV clients.



I don't want to cause undue fear and panic as with time and effort and education and innovation this situation is correctable. But if left to run its course this trend would mean the death of bitcoin. And parasitic[1] systems like mastercoin and counterparty make the situation worse. It's like adding bad weather, stormy seas, and sharks while we're treading water trying to find a solution.



Furthermore, it's simply not necessary. You can accomplish all of Counterparty's goals via off-chain solutions the same or similar security guarantees. There has been a lot of mis-information out there about this! That's why I pointed to the Freimarkets paper I co-authored with jtimon. It's not because I want to claim credit for the idea (it is as old as bitcoin), but to show there are worked out counter-proposals that could be implemented today.



We tried to make very clear from the beginning that OP_RETURN was never meant to be used. Enabling small data commitments is like cooperating with a mugger: losing your pride is preferable to losing your life. Likewise, if you insist on abusing the block chain than please at least don't do something so recklessly stupid and hurtful as a class A mastercoin transaction. Put a hash of the data in the block chain instead. OP_RETURN was only ever meant to contain a hash - 32 bytes.



But ultimately what you *should* be doing is running your own network and have a low-volume mechanism for transferring coins between the two. That helps bitcoin scale and gives you added capabilities like SPV support, pre-signed offers, and scripting extensions.



Our objection from the start has not been "we don't want to see this" but rather "we don't want to see it done in this particular way" because it externalizes costs and makes the situation worse than it already is.



[1] "Parasitic" has a well defined technical meaning and is not meant as a derogatory term here.



@suppow: Hi, it was good to meet you at CoinSummit!



The threats/blacklists/net neutrality discussions aside.



I'm not really sure what viewpoint really stands among core Bitcoin developers as to scalability problems. Peter thinks there is a problem, Gavin thinks it's not a problem - what kind of contribution to data load on the blockchain would constitute 'abuse'? - is there any real danger? At which scale?



What's wrong with charging a fee for each 40 bytes of OP_Return as has been proposed ?- everyone doing transactions that require additional data could switch to that implementation and contribute to network maintenance with fees. If issued assets and smart property indeed blow up to take up a significant fraction of the Network traffic - and a side-chain implementation happens to run shorter block times with 66% less fees - of course people will switch! I just don't understand what advantage there is to be had from a pseudo-factual speculative debate about the effect of this or that as it can or maybe won't happen, when free market forces can be allowed to do the work.



The threats/blacklists/net neutrality discussions aside.I'm not really sure what viewpoint really stands among core Bitcoin developers as to scalability problems. Peter thinks there is a problem, Gavin thinks it's not a problem - what kind of contribution to data load on the blockchain would constitute 'abuse'? - is there any real danger? At which scale?What's wrong with charging a fee for each 40 bytes of OP_Return as has been proposed ?- everyone doing transactions that require additional data could switch to that implementation and contribute to network maintenance with fees. If issued assets and smart property indeed blow up to take up a significant fraction of the Network traffic - and a side-chain implementation happens to run shorter block times with 66% less fees - of course people will switch! I just don't understand what advantage there is to be had from a pseudo-factual speculative debate about the effect of this or that as it can or maybe won't happen, when free market forces can be allowed to do the work.

maaku



Offline



Activity: 905

Merit: 1003







LegendaryActivity: 905Merit: 1003 Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official March 28, 2014, 09:34:23 PM #6388 Every release since 0.7 has included performance improvements as a key feature, starting with the very important merging of Pieter Wuille's ultraprune branch. Remember that this time last year we were ridiculing Peter Todd's "keep bitcoin free" campaign to enshrine the 1MB block limit. Even Peter Todd has switched positions on that one, so I think I can generalize to say that we all see the need for bitcoin to scale to higher traffic levels, and identify many outstanding problems to be solved between here and there. But beyond that I don't feel comfortable commenting on the specific positions of individual developers other than myself.



What's wrong with charging a fee for data use is that it does absolutely nothing to solve the problem. Fees go to miners, not full nodes. You don't collect a single Satoshi for running a full node. And until that incentive problem is fixed (it's not clear it can be), scaling bitcoin up means centralization and degradation of the peer-to-peer network, to the point of becoming compromised or unusable.

If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP I'm an independent developer working on bitcoin-core , making my living off community donations.If you like my work, please consider donating yourself:

prophetx



Offline



Activity: 1624

Merit: 1002





he who has the gold makes the rules







LegendaryActivity: 1624Merit: 1002he who has the gold makes the rules Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official March 28, 2014, 10:10:37 PM

Last edit: March 28, 2014, 10:40:10 PM by prophetx #6389 Quote from: maaku on March 28, 2014, 08:54:02 PM Let me start with the good. There is a reason we (developer hat on) are generally up in arms about "abusive" data-on-blockchain proposals: it is because we see the potential of this tech! We know that issued assets and smart property contracts could grow to eclipse bitcoin traffic entirely. Some of us are even convinced this could happen quickly.



Why is this bad? Because despite bitcoin being in the process of going mainstream and getting all sorts of attention from everybody, everywhere, the number of full nodes is declining. As mentioned by others this is in large part due to the rise of SatoshiDice. Now I don't object to gambling services on bitcoin, nor do I know any other developers who do. What you do with your money is your business. The issue is that SD gave a trivial amount of satoshi's back to indicate a lost bet, which effectively was an uneconomical-to-spend data message similar in size to a class A Mastercoin transaction which Counterparty is sadly now adopting. That drain on the resources of the network from this extra data processing is causing people to turn off their full nodes and switch to SPV clients.



I don't want to cause undue fear and panic as with time and effort and education and innovation this situation is correctable. But if left to run its course this trend would mean the death of bitcoin. And parasitic[1] systems like mastercoin and counterparty make the situation worse. It's like adding bad weather, stormy seas, and sharks while we're treading water trying to find a solution.



Furthermore, it's simply not necessary. You can accomplish all of Counterparty's goals via off-chain solutions the same or similar security guarantees. There has been a lot of mis-information out there about this! That's why I pointed to the Freimarkets paper I co-authored with jtimon. It's not because I want to claim credit for the idea (it is as old as bitcoin), but to show there are worked out counter-proposals that could be implemented today.



We tried to make very clear from the beginning that OP_RETURN was never meant to be used. Enabling small data commitments is like cooperating with a mugger: losing your pride is preferable to losing your life. Likewise, if you insist on abusing the block chain than please at least don't do something so recklessly stupid and hurtful as a class A mastercoin transaction. Put a hash of the data in the block chain instead. OP_RETURN was only ever meant to contain a hash - 32 bytes.



But ultimately what you *should* be doing is running your own network and have a low-volume mechanism for transferring coins between the two. That helps bitcoin scale and gives you added capabilities like SPV support, pre-signed offers, and scripting extensions.



Our objection from the start has not been "we don't want to see this" but rather "we don't want to see it done in this particular way" because it externalizes costs and makes the situation worse than it already is.



[1] "Parasitic" has a well defined technical meaning and is not meant as a derogatory term here.



@Matt: Hi, it was good to meet you at CoinSummit!



how much does it actually cost to run some full nodes?



I'm thinking Mastercoin Foundation and Counterparty could fund several of these with MinerCoin



I'm serious...



Then maybe we can start comping people extra for running the op_return 80 patch that LukeJr suggested.







how much does it actually cost to run some full nodes?I'm thinking Mastercoin Foundation and Counterparty could fund several of these with MinerCoinI'm serious...Then maybe we can start comping people extra for running the op_return 80 patch that LukeJr suggested.

porqupine



Offline



Activity: 214

Merit: 100







Full MemberActivity: 214Merit: 100 Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official March 28, 2014, 10:11:51 PM #6390 Quote from: maaku on March 28, 2014, 09:34:23 PM Every release since 0.7 has included performance improvements as a key feature, starting with the very important merging of Pieter Wuille's ultraprune branch. Remember that this time last year we were ridiculing Peter Todd's "keep bitcoin free" campaign to enshrine the 1MB block limit. Even Peter Todd has switched positions on that one, so I think I can generalize to say that we all see the need for bitcoin to scale to higher traffic levels, and identify many outstanding problems to be solved between here and there. But beyond that I don't feel comfortable commenting on the specific positions of individual developers other than myself.



What's wrong with charging a fee for data use is that it does absolutely nothing to solve the problem. Fees go to miners, not full nodes. You don't collect a single Satoshi for running a full node. And until that incentive problem is fixed (it's not clear it can be), scaling bitcoin up means centralization and degradation of the peer-to-peer network, to the point of becoming compromised or unusable.



Please correct me if I'm misinterpreting what you are saying (and ignore the later points of this post if so) - but I understand the current situation as follows:



a) Currently a very significant problem is lack of incentive for Full Node participation combined with simultaneous Network Scaling

b) Counterparty transactions currently take up 5mb of an 18gb blockchain but if use of counterparty and similar protocols increases dramatically the above problem will be exacerbated before it is possible devise an adequate solution.



If I may, I think just as you don't see it as immediately feasible to address Node incentive and Network scaling, phantomphreak probably doesn't see it as immediately feasible to go from a working secure protocol to a not-yet-coded potentially vulnerable side-chain, for the sake of 40 bytes. Still I doubt there are any serious counterparty or bitcoin users that see a positive future where certain functionality exists at the cost of the health of the entire network as a whole.

As a lot of good developments may come from foresight in implementation, and much can also come from necessity - counterparty as a protocol requires more blocks to be functional (i.e. distributed exchange order matching) than simple sends, if the network even begins to be over-burdened it's effect will be felt there first, and I don't think anyone will continue to use something so unoptimized without moving towards a solution. In the short-term I think Luke Jr's proposal is actually a lot more sensible than at first-glance. Yes, in a way it is undermining net-neutrality and may take a large share of criticism for that - but it also provides a method at least for counterparty and mastercoin to switch to a cleaner implementation (the benefit of which is apparent here and now) without making a seemingly irreversible commit to the protocol at the core.

Again if I'm not misunderstanding: the core developers it seems to me are very naturally worried that to implement a large or limitless OP_Return is to encourage other projects to put similar functionality into the blockchain before node incentive and scaling problems can be addressed.



Please correct me if I'm misinterpreting what you are saying (and ignore the later points of this post if so) - but I understand the current situation as follows:a) Currently a very significant problem is lack of incentive for Full Node participation combined with simultaneous Network Scalingb) Counterparty transactions currently take up 5mb of an 18gb blockchain but if use of counterparty and similar protocols increases dramatically the above problem will be exacerbated before it is possible devise an adequate solution.If I may, I think just as you don't see it as immediately feasible to address Node incentive and Network scaling, phantomphreak probably doesn't see it as immediately feasible to go from a working secure protocol to a not-yet-coded potentially vulnerable side-chain, for the sake of 40 bytes. Still I doubt there are any serious counterparty or bitcoin users that see a positive future where certain functionality exists at the cost of the health of the entire network as a whole.As a lot of good developments may come from foresight in implementation, and much can also come from necessity - counterparty as a protocol requires more blocks to be functional (i.e. distributed exchange order matching) than simple sends, if the network even begins to be over-burdened it's effect will be felt there first, and I don't think anyone will continue to use something so unoptimized without moving towards a solution. In the short-term I think Luke Jr's proposal is actually a lot more sensible than at first-glance. Yes, in a way it is undermining net-neutrality and may take a large share of criticism for that - but it also provides a method at least for counterparty and mastercoin to switch to a cleaner implementation (the benefit of which is apparent here and now) without making a seemingly irreversible commit to the protocol at the core.Again if I'm not misunderstanding: the core developers it seems to me are very naturally worried that to implement a large or limitless OP_Return is to encourage other projects to put similar functionality into the blockchain before node incentive and scaling problems can be addressed.

porqupine



Offline



Activity: 214

Merit: 100







Full MemberActivity: 214Merit: 100 Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official March 29, 2014, 12:08:33 AM #6395 Quote from: dexX7 on March 28, 2014, 11:54:05 PM OP_RETURN can be used to store references to external resources, say for example very long meta transactions that don't fit into 40 byte, an asset contract or whatever. The storage pointed to could be a website which lists something like <hash_used_in_op_return_tx><very_long_message> (for the sake of an example), a side chain or a P2P structure like a DHT. To my knowledge this was discussed several times, but never tested on a broader scale.



That's missing the point, then you're back to the question of how do we securely store data in an accessible, decentralized way, and it's onto side-chains, which come with their own problems and which no one has coded working functionality for - that Counterparty has here and now, and this is for 40 bytes of economy with only pseudo-speculative importance, when as Canton said gambling transactions are taking up 5gb to Counterparty's 5 mb.

I do agree the status of these things may change, but as I wrote, I don't see why speculations about the future should regulate implementation that a freemarket is capable of doing on it's own. That's missing the point, then you're back to the question of how do we securely store data in an accessible, decentralized way, and it's onto side-chains, which come with their own problems and which no one has coded working functionality for - that Counterparty has here and now, and this is for 40 bytes of economy with only pseudo-speculative importance, when as Canton said gambling transactions are taking up 5gb to Counterparty's 5 mb.I do agree the status of these things may change, but as I wrote, I don't see why speculations about the future should regulate implementation that a freemarket is capable of doing on it's own.

sparta_cuss



Offline



Activity: 386

Merit: 250







Sr. MemberActivity: 386Merit: 250 Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official March 29, 2014, 12:19:27 AM #6396 Let me ask a really basic question, since I can't figure it out by reading all of the posts about the 80-->40 OP_Return change and what this means for data stored on the blockchain.



Q: Why does someone run a node?



I understand why miners mine; they earn fees. Nodes do not. So why does someone do it? "We must be willing to let go of the life we have planned, so as to have the life that is waiting for us." - E.M. Forster

NXT: NXT-Z24T-YU6D-688W-EARDT

BTC: 19ULeXarogu2rT4dhJN9vhztaorqDC3U7s