Bitcoin Forum
December 10, 2016, 11:13:37 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 [981] 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1807777 times)
tvbcof
Legendary
*
Offline Offline

Activity: 1988


View Profile
January 04, 2015, 06:23:15 PM
 #19601

I've always been more inclined to favor more of a token system for 'exchange currency' duty.  Under such a 'token flavored sidechain' I would only wish to be able to verify that I am in sole control of my tokens and could induce a particular native Bitcoin retrieval on demand.  For such a system I would accept a certain amount of slop since this would go a long way toward implementation efficiency, and I won't die if I lose (or gain) a few nickles in some sort of a SC failure.

I guess I didnt understand what you meant then (I was thinking privacy).  Still not getting it.

Adam

I had mis-read that somehow cypherdoc was anticipating sidechain data in the mainchain.  One of the reasons I was against this was privacy.

Even a correct reading that there was total transparency within a sidechain system (including at the Bitcoin nexus) has some privacy negatives which I would (for many uses) prefer to avoid when possible.

As I stated, as long as I as a user can be confident that I have 'sole control' of my value in a sidechain, that is all I need.

I do think that people from the top to the bottom tend to get tunnel vision and assume a blockchain architecture to be the only considered solution.  I never did.  I consider it a wonderful solution for 'reserve' duty (often because of the transparency features which are a double-edged sword), but simply not a good match for 'exchange' duty.  Your pal Rusty fell into this trap IMHO though I very much appreciate his conceptions of slop...they guy must be an engineer Smiley

On a theoretical level (mine), tokenized solutions:

 - nix the latency hassles associated with blocks
 - are inherently efficient since the allow 'nature' to be balance sheet which nobody need care about in minute detail.
 - promote (potentially, depending on implementation) privacy due to this lack of need for minute detail accounting.

The change jingling around in one's pocket is a good example of a 'tokenized' system and it works fantastically.  One might say it works 'to well' for some people's tastes and don't know how much longer old-style currency will be hanging on in our modern digital world.


1481368417
Hero Member
*
Offline Offline

Posts: 1481368417

View Profile Personal Message (Offline)

Ignore
1481368417
Reply with quote  #2

1481368417
Report to moderator
1481368417
Hero Member
*
Offline Offline

Posts: 1481368417

View Profile Personal Message (Offline)

Ignore
1481368417
Reply with quote  #2

1481368417
Report to moderator
1481368417
Hero Member
*
Offline Offline

Posts: 1481368417

View Profile Personal Message (Offline)

Ignore
1481368417
Reply with quote  #2

1481368417
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481368417
Hero Member
*
Offline Offline

Posts: 1481368417

View Profile Personal Message (Offline)

Ignore
1481368417
Reply with quote  #2

1481368417
Report to moderator
1481368417
Hero Member
*
Offline Offline

Posts: 1481368417

View Profile Personal Message (Offline)

Ignore
1481368417
Reply with quote  #2

1481368417
Report to moderator
Adrian-x
Legendary
*
Offline Offline

Activity: 1330



View Profile
January 04, 2015, 06:30:36 PM
 #19602

If mtgox had had you design a SC for them, would you have structured a single specific SPVmtgox SC to which everyone would have sent their BTC (one address), then waited 2d for confirmation, before allowing those individuals to be assigned their own specific  scBTC to be traded p2p , all the while securing this SC with 100% MM?

The point of moving transactions on-chain is that the user can then own their own coins, rather than delegating ownership to a third party like mtgox.

Adam


Adam why not support OT. With SC as proposed users don't own there one coin they are trusting the decentralized network managed by pitting incentives to secure the coins.

SC proponents overlook the change SC make to the incentive system and think it's safe.

I'm open to changing my mind,  why don't you put some of that $21m into a peer review economic impact study?

The nonsense you spout about where your profit comes from is damaging to BlockStream's motives.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 04, 2015, 06:37:58 PM
 #19603

Quote from: cypherdoc
Quote from: tvbcof
I've always been more inclined to favor more of a token system for 'exchange currency' duty.  Under such a 'token flavored sidechain' I would only wish to be able to verify that I am in sole control of my tokens and could induce a particular native Bitcoin retrieval on demand.  For such a system I would accept a certain amount of slop since this would go a long way toward implementation efficiency, and I won't die if I lose (or gain) a few nickles in some sort of a SC failure.

none of what you're saying then makes sense compared to what Adam has been saying.

SC's are blockchains except in the case of federated server SC's (but even that definition is being fuzzed over by the SC ppl calling an internal ledger a SC  Huh)

I think it was more JorgeStolfi with the internal ledger (the sofa/couch in bitstamps office?),  I would not call an internal ledger a chain - a chain has to be real-time publicly audited  I think, to be called a chain.

With federated peg there is a real side-chain, including mining, consensus rules etc and then the federated peg servers act as a protocol adaptor - the peg servers are full nodes on the side-chain, and pegged coins are paid to their multisig address (eg 10 of 15) and the side-chain fullnodes and miners watch the multisig address on the bitcoin network, and coins arriving there count as a peg to put coins into the side-chain; and when the side-chain hashrate majority approves a return peg to reanimate a coin, the federated pegs are watching the side-chain as they are full nodes there too, so they release the funds to the address the return peg tells them to.

Now obviously the limitation is if >= 10 of the federated peg servers are hostile or compromised, they could take the coin without approval of the side-chain.  But short of that it is the side-chain consensus and miners etc that arbitrate what coins move across the peg.

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
tvbcof
Legendary
*
Offline Offline

Activity: 1988


View Profile
January 04, 2015, 06:49:36 PM
 #19604


Adam why not support OT. ...

Maybe for the same basic reason you don't get into the car with the nice man who offers you candy.


JorgeStolfi
Hero Member
*****
Offline Offline

Activity: 868



View Profile
January 04, 2015, 06:49:55 PM
 #19605

What is it exactly that prevents those potential COIN buyers from buying BTC directly, or SMBIT shares?   The fact that they are not traded on an exchange like NASDAQ?  Or some intrinsic property of the asset?

Note that COIN shares will uninsured against theft or loss, besides being backed only by a "stock" (BTCs) that itself has no backing assets.

Permit me to quote myself from another thread.....

Quote
One point that's been overlooked in this discussion: ETFs allow institutional and qualified/professional investors to purchase regulated securities, pursuant either to their own internal bylaws and product placement memoranda, or to securities laws by which they must abide. For example, a professional investment fund, such as a mutual fund or hedge fund or pension fund, is limited in how it may allocate investors' funds insofar as the fund is only permitted to purchase securities regulated under such-and-such provisions. A fund may indeed wish to purchase bitcoins right now, but it cannot due to the aforesaid regulatory provisions; however an ETF investment vehicle would allow the fund to purchase shares in the bitcoin ETF right now, shares that would presumably track the Bitcoin price, and may be bought, sold, and traded—in a regulated environment—as any other shares would be.

Well, my question above was not rhetorical.  Is the fact that the ETF is listed on NASDAQ sufficient to enable those restricted investments?  Or are there other conditions that depend on the nature of the fund and its assets?

Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
MarketNeutral
Sr. Member
****
Offline Offline

Activity: 364


View Profile
January 04, 2015, 06:52:13 PM
 #19606

Quote from: cypherdoc
Quote from: tvbcof
I've always been more inclined to favor more of a token system for 'exchange currency' duty.  Under such a 'token flavored sidechain' I would only wish to be able to verify that I am in sole control of my tokens and could induce a particular native Bitcoin retrieval on demand.  For such a system I would accept a certain amount of slop since this would go a long way toward implementation efficiency, and I won't die if I lose (or gain) a few nickles in some sort of a SC failure.

none of what you're saying then makes sense compared to what Adam has been saying.

SC's are blockchains except in the case of federated server SC's (but even that definition is being fuzzed over by the SC ppl calling an internal ledger a SC  Huh)

I think it was more JorgeStolfi with the internal ledger (the sofa/couch in bitstamps office?),  I would not call an internal ledger a chain - a chain has to be real-time publicly audited  I think, to be called a chain.

With federated peg there is a real side-chain, including mining, consensus rules etc and then the federated peg servers act as a protocol adaptor - the peg servers are full nodes on the side-chain, and pegged coins are paid to their multisig address (eg 10 of 15) and the side-chain fullnodes and miners watch the multisig address on the bitcoin network, and coins arriving there count as a peg to put coins into the side-chain; and when the side-chain hashrate majority approves a return peg to reanimate a coin, the federated pegs are watching the side-chain as they are full nodes so they release the funds to the address the return peg tells them to.

Now obviously the limitation is if >= 10 of the federated peg servers are hostile or compromised, they could take the coin without approval of the side-chain.  But short of that it is the side-chain consensus and miners etc that arbitrate what coins move across the peg.

Adam


Adam, would you mind clarifying a few things? I do understand the core blockchain system quite thoroughly, but these side-chain concepts are new to me and I want to make sure I understand. Correct me if I'm wrong, but a federated peg would be easier to implement than a SNARK peg or a SPV peg, right? No hard or soft fork? But on the other hand, am I correct to assume that the failure points of a federated peg are theoretically more dangerous?

Moreover, as one whose company is currently developing private mining hardware, how do these peg/token side chains directly affect the bitcoin mining protocol (in terms of the block header's nonce, merkle root, etc), if at all? Absent a fork, nothing changes?
JorgeStolfi
Hero Member
*****
Offline Offline

Activity: 868



View Profile
January 04, 2015, 06:59:36 PM
 #19607

picolo, TonyT, there are VERY precise statistics of exactly this (just not by "person", only by "bitcoin").  All of the data is in the block chain.  Anyone can see precisely when every bitcoin was last transferred.  There are also pretty good data on exchange rates to whatever your favorite currency is (if not bitcoin).  Every UTXO exists in a timestamped block.

Ratcliff has put together some nice area charts showing the age.
http://www.reddit.com/r/Bitcoin/comments/2n205b/an_area_chart_showing_the_distribution_of/

So to answer your question, most bitcoin were last transferred at well under the current price.

Note that the most recent transaction may not be when the coins last changed hands.

If the price had been increasing all the time, the output amount X in an UTXO times the price P(t) at that time would be only an upper bound to the purchase price of those coins.   However, because of the subtantial drops in price, and the large trade volumes during price drops, not even that is true.   Moreover, coins that are deposited on the exchanges are changing hands without a corresponding record in the blockchain. 

Academic interest in bitcoin only. Not owner, not trader, very skeptical of its longterm success.
MarketNeutral
Sr. Member
****
Offline Offline

Activity: 364


View Profile
January 04, 2015, 07:08:03 PM
 #19608

What is it exactly that prevents those potential COIN buyers from buying BTC directly, or SMBIT shares?   The fact that they are not traded on an exchange like NASDAQ?  Or some intrinsic property of the asset?

Note that COIN shares will uninsured against theft or loss, besides being backed only by a "stock" (BTCs) that itself has no backing assets.

Permit me to quote myself from another thread.....

Quote
One point that's been overlooked in this discussion: ETFs allow institutional and qualified/professional investors to purchase regulated securities, pursuant either to their own internal bylaws and product placement memoranda, or to securities laws by which they must abide. For example, a professional investment fund, such as a mutual fund or hedge fund or pension fund, is limited in how it may allocate investors' funds insofar as the fund is only permitted to purchase securities regulated under such-and-such provisions. A fund may indeed wish to purchase bitcoins right now, but it cannot due to the aforesaid regulatory provisions; however an ETF investment vehicle would allow the fund to purchase shares in the bitcoin ETF right now, shares that would presumably track the Bitcoin price, and may be bought, sold, and traded—in a regulated environment—as any other shares would be.

Well, my question above was not rhetorical.  Is the fact that the ETF is listed on NASDAQ sufficient to enable those restricted investments?  Or are there other conditions that depend on the nature of the fund and its assets?

Yes, NASDAQ is more than sufficient. Generally speaking, any security listed on a major exchange, such as NASDAQ or DJIA, is considered adequately regulated for institutional and professional investment purposes. Another way to look at it is, in the United States for example, if the SEC, FINRA, DTCC, or NASAA are involved, then the investments are in theory permissible on a professional level. Similar regulatory boards and enforcement agencies in other countries operate in much the same way.

There are exceptions, mostly contingent upon the nature of the fund that's investing and other factors such as the clients' risk profile or initial investment amount.

There are plenty of professional investors who would love to invest in exotic, high-risk instruments such as Bitcoin, but they also know that if they don't follow the law, i.e., investing clients' funds in regulated securities markets, then they can easily be sued and shuttered into oblivion.

At the highest levels of finance, most of what investors spend there time on is considering investments against possible litigation.
tvbcof
Legendary
*
Offline Offline

Activity: 1988


View Profile
January 04, 2015, 07:21:25 PM
 #19609


Adam, would you mind clarifying a few things? I do understand the core blockchain system quite thoroughly, but these side-chain concepts are new to me and I want to make sure I understand. Correct me if I'm wrong, but a federated peg would be easier to implement than a SNARK peg or a SPV peg, right? No hard or soft fork? But on the other hand, am I correct to assume that the failure points of a federated peg are theoretically more dangerous?

Moreover, as one whose company is currently developing private mining hardware, how do these peg/token side chains directly affect the bitcoin mining protocol (in terms of the block header's nonce, merkle root, etc), if at all? Absent a fork, nothing changes?

If you would allow me to chime in only because it offers an opportunity to propose REAL potential problems with sidechains and not phony simplistic self-serving nonsense ones.

As I see things, sidechains effect Bitcoin simply as large, well funded, often fairly active whales.  Nothing more, and it doesn't matter how they work in their own back-ends (chains, tokens, ledgers, distributed, proprietary, whatever.)  These whales happen to really really really want Bitcoin to work because their lives depend on it (with one exception shown below.)

Problems:

 1) being well-funded, the whales could crowd out other users of native Bitcoin.

 2) these whales might get into battles with one another and try to use native Bitcoin as a cudgel causing collateral damage.

 3) One whale might become so successful it may at least think it can swallow Bitcoin whole and take over (what I call 'shooting the moon.')

 edit - 4) A 'seismic event' within a sidechain could create a undesirable transient in native Bitcoin activity.

I'll defer to Adam on the number of sidechain implementations he sees.  He's stated it as a small integer as I recall.  I would hope for many more in part because it would help to mitigate against some of the potential problems I see.


adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 04, 2015, 07:55:16 PM
 #19610

Oh boy, thats another can of worms.  You dont happen to work for conformal do you btw?

So (it a long story) but a) no one knows who's funding them; b) most of them seem to have ex-defence contractor profiles; c) no one knows why they are coding it; d) if there is one off by even a single bit interpretation bug in it it breaks consensus and forks bitcoin, which can likely be systematically abused, to create a massive accounting/double-spend mess that will be too expensive to repair as last time - that could create a mega fork worse than the leveldb bug, and kill bitcoin or force some really harsh choices to best effort cleanup where there are innocent losers; e) it apparently took a lot of effort by the core devs to persuade them that this was a problem; f) it still has that problem.

d) This is a complete red herring and exists just as much with Bitcoin Core as it does with anything else.  The exact same thing can easily happen (and already has as you've noted) with Bitcoin Core.  This is a real problem with the technology that needs to be solved independent of the number of implementations on the network.  In fact, working toward solutions which address this fundamental issue is necessary for Bitcoin Core too since it means mistakes there don't lead to undesirable consequences either.  The current approach is "well let's just hope it doesn't happen!" and frankly, that just isn't good enough.

about why consensus is hard, and more so for two different implementations, here are two presentations first on language security as it applies to host security and software compatibility and second on bitcoin consensus.  The first is quite eye opening even for security researchers (ie people who are experts in host security).

language security https://archive.org/details/The_Science_of_Insecurity_

bitcoin consensus programming https://www.youtube.com/watch?v=on5ySFK0aoY#t=39m50s

Have a listen, particularly to the first one and then we can discuss further (here or PM or bitcoin-dev or #bitcoin-wizards or whereever).  I am genuinely interested to help resolve the discrepancy of opinion around this, as its actually to my mind significantly misunderstood, and dangerous for bitcoin.

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
MarketNeutral
Sr. Member
****
Offline Offline

Activity: 364


View Profile
January 04, 2015, 07:55:50 PM
 #19611


Adam, would you mind clarifying a few things? I do understand the core blockchain system quite thoroughly, but these side-chain concepts are new to me and I want to make sure I understand. Correct me if I'm wrong, but a federated peg would be easier to implement than a SNARK peg or a SPV peg, right? No hard or soft fork? But on the other hand, am I correct to assume that the failure points of a federated peg are theoretically more dangerous?

Moreover, as one whose company is currently developing private mining hardware, how do these peg/token side chains directly affect the bitcoin mining protocol (in terms of the block header's nonce, merkle root, etc), if at all? Absent a fork, nothing changes?

If you would allow me to chime in only because it offers an opportunity to propose REAL potential problems with sidechains and not phony simplistic self-serving nonsense ones.

As I see things, sidechains effect Bitcoin simply as large, well funded, often fairly active whales.  Nothing more, and it doesn't matter how they work in their own back-ends (chains, tokens, ledgers, distributed, proprietary, whatever.)  These whales happen to really really really want Bitcoin to work because their lives depend on it (with one exception shown below.)

Problems:

 1) being well-funded, the whales could crowd out other users of native Bitcoin.

 2) these whales might get into battles with one another and try to use native Bitcoin as a cudgel causing collateral damage.

 3) One whale might become so successful it may at least think it can swallow Bitcoin whole and take over (what I call 'shooting the moon.')

I'll defer to Adam on the number of sidechain implementations he sees.  He's stated it as a small integer as I recall.  I would hope for many more in part because it would help to mitigate against some of the potential problems I see.



There are many brilliant people working on crypto technologies, but they are so in love with the technology and with their own ideas, they neglect to consider how their academic, theoretical work may apply to the world of finance. After all, bitcoin directly relates to finance. Whether one considers bitcoin money or a commodity or a hybrid thereof, it unequivocally falls in the realm of finance just as much as it falls in the realm of programming, hacker culture, and crypto maths. I like all this stuff, so it's easy for me to get excited and follow along, but as a finance professional, I also see the other, sorely neglected side of the proverbial coin. The disconnect is enormous. (They would make great quants, haha.) I too often see bitcoin's brightest minds focusing on the minutiae of esoteric problems, while not unimportant, are not the immediate issues bitcoin merchants and users are interested in.

Your post about a "whale" disrupting things is very interesting and not as far-fetched as some would believe.

At this point, I think it's very important for people working on Bitcoin, sidechains, and all blockchain-related technologies, whatever they may be, to clearly state in lay terms WHY their work is important and necessary, which is to say, what problems their proposed solutions solve. Satoshi was very good at this.

I also will defer to Adam on sidechain implementation. He seems to have an incredible and deep grasp of how they may function.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
January 04, 2015, 07:55:59 PM
 #19612

He thinks he can get to 100k TPS.
What's the problem with doing 100k TPS on the main chain?

(other than non-answers like "it's hard to do")
sgbett
Legendary
*
Offline Offline

Activity: 1330



View Profile
January 04, 2015, 08:03:03 PM
 #19613

I didn't say it *was* going to go up - as you noticed I used the word if (just like you did). There are a thousand other threads debating whether the price will go up or down.I'm not arguing that it will, so I don't know why you are bring that up.

By using if there is an implicit assumption that the contrary is also true - *if* people all sell the ETF and the price goes down it will force the BTC price down through arb.

Indeed; my apologies for the undue reading of your post.

No worries, very Gentleman! Smiley

http://haschinabannedbitcoin.com
Full Node: http://46.51.193.129 (BU)
"A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution" - Satoshi Nakamoto
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
January 04, 2015, 08:03:53 PM
 #19614

Some bizarre form of Tourette Syndrome
If you have trouble understanding how businesses survive the economic reality that competition in a free market reduces the profitability of all ventures over time, then maybe you can go ask them for yourself how they manage to deal with it?

There are millions of them in the world, so it shouldn't be too hard to find a few and talk with them.

Let us know how your investigation goes.
tvbcof
Legendary
*
Offline Offline

Activity: 1988


View Profile
January 04, 2015, 08:17:25 PM
 #19615

Some bizarre form of Tourette Syndrome
If you have trouble understanding how businesses survive the economic reality that competition in a free market reduces the profitability of all ventures over time, then maybe you can go ask them for yourself how they manage to deal with it?

There are millions of them in the world, so it shouldn't be too hard to find a few and talk with them.

Let us know how your investigation goes.

In other words 'because free market' and 'because sound money'.  Typical Libertardian fallback to a non-answer.  Why should I have hoped for more?


adam3us
Sr. Member
****
Offline Offline

Activity: 400


in bitcoin we trust


View Profile WWW
January 04, 2015, 08:18:20 PM
 #19616

With federated peg there is a real side-chain, including mining, consensus rules etc and then the federated peg servers act as a protocol adaptor - the peg servers are full nodes on the side-chain, and pegged coins are paid to their multisig address (eg 10 of 15) and the side-chain fullnodes and miners watch the multisig address on the bitcoin network, and coins arriving there count as a peg to put coins into the side-chain; and when the side-chain hashrate majority approves a return peg to reanimate a coin, the federated pegs are watching the side-chain as they are full nodes so they release the funds to the address the return peg tells them to.

Now obviously the limitation is if >= 10 of the federated peg servers are hostile or compromised, they could take the coin without approval of the side-chain.  But short of that it is the side-chain consensus and miners etc that arbitrate what coins move across the peg.

[...] side-chain concepts are new to me and I want to make sure I understand. Correct me if I'm wrong, but a federated peg would be easier to implement than a SNARK peg or a SPV peg, right? No hard or soft fork?

Right no changes needed.

Quote from: MarketNeutral
But on the other hand, am I correct to assume that the failure points of a federated peg are theoretically more dangerous?

Yes failure modes kick in if the threshold of federated servers is compromised or untrustworthy, and could be worse as there is more flexibility on coding smart-contract enforced limits with the spv-peg (or for now hypothetical snark-peg).

Quote from: MarketNeutral
Moreover, as one whose company is currently developing private mining hardware, how do these peg/token side chains directly affect the bitcoin mining protocol (in terms of the block header's nonce, merkle root, etc), if at all? Absent a fork, nothing changes?

Nothing changes for hw miners.  Any changes are in the pool (local or remote) the miners are connected to - which fullnodes its getting merkle information from.

I'd say outside of side-chains, and just in general, a soft-fork (or even 99% of conceivable hard-forks) the mining algorithm would not change.  The miners just need some basic formatting about headers to continue to work and they're fine as is.

I think the unlikely because of self-preservation, but main way hypothetically you'd see mining change is if miners got far too centralised and it became an disruptive day to day problem for bitcoin security, and mining operators rejected or ignored complaints, the economic majority could eventually fell forced to defensively break the current deployed ASICs with a minor software change.  The so-called 'big-red-button'.  Its not fun in any direction because it leads to erratic hashrate risks from the hash-rate shake up as GPUs & FPGAs are reshuffled and revised ASICs fast-tracked.

Adam

hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
markj113
Legendary
*
Offline Offline

Activity: 1358



View Profile
January 04, 2015, 08:26:23 PM
 #19617

Gold outperformed every currency apart from the US $ in 2014, 0.8% down on the year



I think most people know how the US $ will end up so get some gold while you can Smiley
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
January 04, 2015, 08:29:33 PM
 #19618

Some bizarre form of Tourette Syndrome
If you have trouble understanding how businesses survive the economic reality that competition in a free market reduces the profitability of all ventures over time, then maybe you can go ask them for yourself how they manage to deal with it?

There are millions of them in the world, so it shouldn't be too hard to find a few and talk with them.

Let us know how your investigation goes.

Don't bother with the simpleton.

He's been operating under the assumption that SC's are token, not blockchains, lol. 

And  what about his blather above that accounting doesn't need to pay attention to details, lol?
tvbcof
Legendary
*
Offline Offline

Activity: 1988


View Profile
January 04, 2015, 08:37:30 PM
 #19619

Some bizarre form of Tourette Syndrome
If you have trouble understanding how businesses survive the economic reality that competition in a free market reduces the profitability of all ventures over time, then maybe you can go ask them for yourself how they manage to deal with it?

There are millions of them in the world, so it shouldn't be too hard to find a few and talk with them.

Let us know how your investigation goes.

Don't bother with the simpleton.

He's been operating under the assumption that SC's are token, not blockchains, lol. 

And  what about his blather above that accounting doesn't need to pay attention to details, lol?

I notice that cypherdoc also avoided my very simple and easy to understand question like the plague.  I'll give you two a few days to come up with some sort of a plausible answer, but won't expect much more than 'because free market.'

BTW, I know first hand how 'they manage to deal with it', and it's not pretty.  Certainly it's not where I want to see Bitcoin go whether it makes me a fortune or not.


cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
January 04, 2015, 08:43:25 PM
 #19620

Quote from: cypherdoc
Quote from: tvbcof
I've always been more inclined to favor more of a token system for 'exchange currency' duty.  Under such a 'token flavored sidechain' I would only wish to be able to verify that I am in sole control of my tokens and could induce a particular native Bitcoin retrieval on demand.  For such a system I would accept a certain amount of slop since this would go a long way toward implementation efficiency, and I won't die if I lose (or gain) a few nickles in some sort of a SC failure.

none of what you're saying then makes sense compared to what Adam has been saying.

SC's are blockchains except in the case of federated server SC's (but even that definition is being fuzzed over by the SC ppl calling an internal ledger a SC  Huh)

I think it was more JorgeStolfi with the internal ledger (the sofa/couch in bitstamps office?),  I would not call an internal ledger a chain - a chain has to be real-time publicly audited  I think, to be called a chain.

With federated peg there is a real side-chain, including mining, consensus rules etc and then the federated peg servers act as a protocol adaptor - the peg servers are full nodes on the side-chain, and pegged coins are paid to their multisig address (eg 10 of 15) and the side-chain fullnodes and miners watch the multisig address on the bitcoin network, and coins arriving there count as a peg to put coins into the side-chain; and when the side-chain hashrate majority approves a return peg to reanimate a coin, the federated pegs are watching the side-chain as they are full nodes there too, so they release the funds to the address the return peg tells them to.

Now obviously the limitation is if >= 10 of the federated peg servers are hostile or compromised, they could take the coin without approval of the side-chain.  But short of that it is the side-chain consensus and miners etc that arbitrate what coins move across the peg.

Adam


Ok, this is new info to all of here who assumed federated server implementations of SC's were just that, server based only,  without blockchains. This sounds more like a Ripple type system with gateways and a blockchain. 
Pages: « 1 ... 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 [981] 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 ... 1560 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!