Bitcoin Forum
June 03, 2015, 09:40:12 PM *
News: Latest stable version of Bitcoin Core: 0.10.2 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 201 »
481  Bitcoin / Development & Technical Discussion / Re: Faster bitcoin transaction times on: November 01, 2014, 10:07:38 PM
I don't believe that money can be or is evil. And getting paid is something that I'd never begrudge people for. What you're attempting to do there, however, is not to get paid for your work: You're attempting to get paid for other people's work (including mine, as a matter of fact), which made whatever you done possible and for which you did not pay a single bitcent. You are also attempting to get paid for the work other people may do in the future completely independently of you.  I consider this to be despicable and many other in our ecosystem will as well.  If you'd like to do useful work you can certainly find people to pay you to do so... if you're willing to actually do work, rather than spin your wheels encumbering the work others have done, I've certainly never complained about being unable to earn a living. (I thought I was clear that donations only amounted to a tiny amount? I've really tried to call for them.)  I worked on Bitcoin prior to having any expectation that it would make any money for me, it's an interesting technology which I believe is important for human freedom in the future (including my own and my families: my community work is not selfless, it's just merely not exploitive either).

Quote
Which let's face it, is only an issue if over approximately 50% of the forging stake is running a version of the software that tries to be selfish and work together to form attacking branches.
Ah, this demonstrates you don't actually understand the issue there at all. Sad. I think it's explained quite clearly, but then again I've been working in this space for many years. It's a bit much to ask people to have a strong understanding of anything new to them in only six months.

Considering your lack of understanding of the basic technology, this tangent is probably uninteresting (that it's unlikely that you've found anything which is new and interesting or even secure in a meaningful sense). I recommend you confine your posts to the NXT thread rather than cropping up here to pump it and irritating others.

I'd demand that you stop pumping and actually post your design-- except since you've announced an intention obtain a monopoly ownership interest in the idea (and, accordingly, any cryptocurrency that used it), I wouldn't want to encourage anyone else in the ecosystem to review it and provide you with even more free labor to exploit for your personal gains.
482  Bitcoin / Development & Technical Discussion / Re: What are checkpoints in bitcoin code? on: November 01, 2014, 09:47:55 PM
No it doesn't. It can skip verifying very deeply burred signatures (as is the checkpoint behaviour), since with headers first it knows the amount of work on top of them and can perform the tests only probabilistically past a certain point.
Is this planned for the reference client (along with fraud proofs, presumably)?
Pieter and I-- at least-- have been talking about it for a while as part of the motivation for headers first, even prior to the fraud proofs: past some limit (E.g. max(60days work at the highest difficulty ever observed in the best chain, 2016 blocks) ) a huge reorganization at tip is a guaranteed system failure. (Once you cross 100 blocks a reorg starts forever invalidating an exponentially expanding cone of transactions).   For a while this wasn't as interesting because the total time to replace the chain with the tips hashrate was very low, but it's finally expanding nicely: http://bitcoin.sipa.be/powdays-50k.png

Another potential softer safety mechanism is simply holding the confirmation count in the RPC at zero when there has been a 'system failure grade' reorganization to allow time for a "higher process" to sort out the mess. This also needs a couple other pieces to be completely useful, like the ability to manually invalidate a block over the RPC.

First priority was getting headers first in, tested, and mature.

Obviously fraud proofs have been on my mind for a long time, but they have a lot of protocol surface area. The recent reorganizations of Bitcoin core (e.g. libscript work) will make it easier to work on them with confidence, e.g. be able to build an external process that receives and checks fraud proofs.
483  Bitcoin / Development & Technical Discussion / MOVED: transaction does not reach .. on: November 01, 2014, 09:40:41 PM
This topic has been moved to Technical Support.

https://bitcointalk.org/index.php?topic=843061.0
484  Bitcoin / Development & Technical Discussion / Re: Faster bitcoin transaction times on: November 01, 2014, 09:10:24 PM
Also, I love cryptocurrency and I think it's got a bright shiny future ahead of it.. I'll be honest I'm mostly invested in it because I wanted to make money and the reason I invented this algorithm was because I was looking to make money and help out Nxt, and I don't think that's selfish.. you got in early right?  Why haven't you sold your Bitcoins and worked on Bitcoin for minimum wage in order to be selfless?
I've worked on Bitcoin for years without payment, and made no magical "early money" on account of having worked on it (it isn't like working on the software results in it paying you... outside of some scammy premined alts Smiley, I think I've probably collected a dozen or so in donations, on account of open source work on Bitcoin), and made a conscious and intentional decision to not patent or restrictive license many piece of novel technology used in the ecosystem. Bitcoin is a revolutionary technology which has the potential to improve people's personal freedom and autonomy and allow more of the world to interact as equals. This potential cannot be realized-- cryptocurrency has no future-- if the system is owned or monopolized through state granted artificial property rights. Bitcoin is also the logical progression of the work of thousands of people over many years, without which Bitcoin would not have been possible.

I think that it's unfortunate that providing freedom to the world also includes greedy parasites who think it's acceptable to go around trying to take small (and usually obvious) extensions of a system that was shared freely with them and take them away from the public for their personal gain. But fact that you're based on NXT at all suggests that you don't actually have the technical background to gauge a secure system from an insecure one, so, well, good luck with that. In the unlikely event that what you've done is at all worthwhile, I'll personally endeavour to ensure that it's replaced with superior unencumbered alternatives so that they only thing you receive on account of your anti-social behaviour is lost income.

If anyone is threated on patent grounds by mczarnek or anyone else involved with the seedy "NXT" project now or in the future and finds this message, please feel free to reach out to me for technical, legal, or financial assistance. I've worked on defending against patents successfully for many years and would be glad to help anyone work around, uncover prior art, or otherwise invalidate patents in this space. Cheers.
485  Bitcoin / Development & Technical Discussion / Re: Faster bitcoin transaction times on: November 01, 2014, 08:05:17 PM
Actually, I'm in the process of patenting a decentralized, secure, fast instant transaction system.. should be easily able to be integrated into Bitcoin at which I'll have to see if Bitcoin is willing to buy the patent off of me.  We're sticking it into Nxt first though, partially to test if it works.  Should provide sub second transaction confirmations and works nicely with the current blockchain implementations.
Patenting your idea will almost certainly guarantee its complete failure, patented cryptosystems are almost never deployed and there is a long history proving this out. Your patent will also likely be invalid, since it was almost certainly anticipated by the years a public work in support of the community done by people here and in other places. Even ignoring the situation specific factors, in the US a majority of patents have claims struck down on review; for small inventors the patent system is a scam to make money for attorneys and the patent office: the patents they get are usually unenforceable for legal (invalidity) or economic (patent litigation costs hundreds of thousands of dollars and ruins good will, so a small inventor can almost never afford it and everyone knows it) reasons.

If your idea is actually useful, you should make it available publicly where it can be reviewed and refined and have some chance of adoption and building your professional credibility. If you instead go the route of patenting it, then even if the idea is unworkable (which it likely is, most cryptographic proposals turn out to be flawed) you will have only been successful as identifying yourself as a thief who has taken from the enormous body of work in Bitcoin and the wider cryptocurrency and cryptographic ecosystem given to your freely and attempted to lock up part of it for your personal profit at the expense of everyone else who you've benefited from.

Quote
I read somewhere that 0-confirmation transactions can be made fairly safe with a mathematical calculation. So that in combination with simple changes in the Bitcoin software to increase the number of transactions per second is a better solution.
I read somewhere that the moon is made of green cheese. ... you might want to be a bit more specific.

Zero confirmations are inherently somewhat unsafe-- inherently due to physics, a decentralized system cannot have an instant consensus because light has a finite speed. As far as I am aware zero-conf cannot magically be made substantially more safe without invoking a trusted party in some manner. There are many proposals for instant payments that involve things like escrowed coins (E.g. micropayment channel hubs), but they all make some additional security compromise (though potentially a small one).  I am not aware of any magical mathematical calculation that helps you.

Federated servers are a form of centralization, an improved one-- for sure, which may be suitable for many applications. Man would it be nice if they weren't.
486  Bitcoin / Development & Technical Discussion / Re: What are checkpoints in bitcoin code? on: November 01, 2014, 07:53:15 PM
Good point. Parallel downloading is awesome. But the CPU still has to crunch ALL those EC verifies. ::sigh::
No it doesn't. It can skip verifying very deeply burred signatures (as is the checkpoint behaviour), since with headers first it knows the amount of work on top of them and can perform the tests only probabilistically past a certain point.
487  Bitcoin / Development & Technical Discussion / Re: What are checkpoints in bitcoin code? on: November 01, 2014, 07:50:14 PM
I still have not heard a reasonable argument as to why this can't/won't work.
Because it doesn't make any sense. Lets say you program nodes to enforce some criteria burred in a chain they're handed.  Great now I create a simulated history which that sets a bogus 'checkpoint' back early in the chain, but any _new_ nodes that attach to me I give this simulated history to before they know there is a better chain elsewhere and they start enforcing that rule and they are now forked off onto this bogus alternative chain; so you've introduced a vulnerability. Worse, because the forking off can be arbitrarily far back it becomes exponentially cheaper to do so long as hash-power is becoming exponentially cheaper.

This is even _before_ getting to the argument that what you're suggesting weakens the security model even if it works fine:  The result is that you give miners a new power, instead of just being able to reorder the history, they could also create arbitrary inflation just by adding new utxo to their updates. (which, if course, would be in all of their short-term interests to do)

488  Bitcoin / Development & Technical Discussion / MOVED: New rpcallowip settings? on: November 01, 2014, 08:29:50 AM
This topic has been moved to Technical Support.

https://bitcointalk.org/index.php?topic=842503.0
489  Bitcoin / Development & Technical Discussion / Re: What are checkpoints in bitcoin code? on: November 01, 2014, 08:28:52 AM
Far better to just get rid of them: Headers first makes most reasons obsolete.  The circus above doesn't really help, since it's using the chain itself, which of course checkpoints distort the selection of, so it's just circular.
490  Bitcoin / Development & Technical Discussion / Re: Funding network security in the future on: October 30, 2014, 11:59:04 PM
Verification is more important, yes. But I expect that the total cost of hashing will be much, much higher than the total cost of tx processing (this is of course the case now - there's a $500M / yr market of mining hardware, but no similar market of network nodes). Hence, when talking about hashing, I consider the capacity cheap.

The reason for this is simple - mining is deliberately made artificially difficult. Tx processing is not.
Ah, but mining is not made artificially difficult in any absolute sense. It's whatever it needs to be to keep the target pace. The system operates fine, though its insecure with the difficulty at 1.  The hardware investments are one time, they amortize, energy usage is what is actually interesting. I know I'm not saying anything you don't know,  but I don't know why you expect a particular cost for hashing without first starting with an income (e.g. transaction fees) which would sustain it.
491  Bitcoin / Hardware / MOVED: Hardware Liquidation on: October 30, 2014, 11:03:39 PM
This topic has been moved to Computer hardware.

https://bitcointalk.org/index.php?topic=839685.0
492  Bitcoin / Development & Technical Discussion / Re: Funding network security in the future on: October 30, 2014, 10:47:40 PM
(an incentive for the user to give up on a beneficial tx to conserve a resource which is, in absolute terms, cheap).
I disagree here. Network capacity is not very cheap... It is cheap marginally to miners but thats because the trust cost of a transaction is largely an externality to miners. It's also cheap in a highly centralized network where there is only one or a few verifiers, but in a highly decentralized network much less so. Security does not come exclusively from miners, it comes _primarily_ from verification. Miners serve to provide ordering, an essential part of the system, but miners incentive are aligned by all the other parties verifying (otherwise, a rational thing for all miners to do would be to just agree to inflate the currency forever).
493  Bitcoin / Development & Technical Discussion / Re: Funding network security in the future on: October 30, 2014, 10:26:42 PM
I believe a good proxy for this is the total number of coins transferred in the tx.
Probably not, due to all the non-bitcoin overlay things people are interested in. (E.g. the altcoins, colored coins, etc).

I disagree with the claim that its unrelated. Scarcity of block space is what enables a market for it; absent complete miner collusion, with unlimited block sizes there is a defection problem (the rational move for the miner is to take very low fee paying transactions instead of turning their nose up at them in order to drive the market price for fees above zero).
494  Bitcoin / Development & Technical Discussion / Re: A(nother) downside to Proof-of-Stake? on: October 30, 2014, 09:46:31 PM
A workaround would be for each output to have 2 keys, a spending key and a POS key.
This would allow users to upload their POS key(s) to a mining pool without that pool being able to spend their money.
Yup, But doing that also eliminates some of the incentive alignment arguments in the first place: E.g. that you'll take care of your keys, and not delegate (or do so only cautiously), not leak them, etc.. because your funds depend on them.

Sort of moot because the whole approach seems fundamentally unsound (or at least none of its advocates have stated a clear set of reasonable assumptions under which their system is secure (and where a centralized ledger wouldn't be)). https://download.wpsoftware.net/bitcoin/pos.pdf
495  Bitcoin / Development & Technical Discussion / MOVED: Bitcoin 2.0 When and how will they update it? I am clueless on: October 30, 2014, 09:43:51 PM
This topic has been moved to Beginners & Help.

https://bitcointalk.org/index.php?topic=840371.0
496  Bitcoin / Development & Technical Discussion / Re: Funding network security in the future on: October 29, 2014, 09:27:19 PM
Hm. I'll think about this more before I answer, I don't want to waste anyone's time. I don't think that refutes what I'm saying though, basically because the point I'm making is that the higher hash-power node have lower-overhead per transaction due to the very fact that they are getting blocks faster. It's a kind of positive-feedback loop for the best miners.
I agree with that argument in general, and I think many other people have made it somewhat different forms as well...  But so long as the node operating cost is insignificant, I think it doesn't apply.
497  Bitcoin / Development & Technical Discussion / Re: Funding network security in the future on: October 29, 2014, 08:52:01 PM
I would expect that once inflation stops, transaction fees will not be enough for the vast majority of nodes to stay in operation
Are you missing that the transaction load (and thus cost) is limited by the hard rules of the network, just as the supply of coins is... under the current rules there is no risk of nodes becoming too expensive to run. (I just ask because you used such absolute language in you message).
498  Bitcoin / Development & Technical Discussion / Re: Funding network security in the future on: October 29, 2014, 05:42:47 AM
the P2P node network could configure itself as a giant parallel processor,
This cannot be done with the design of Bitcoin today.  I've previously (incompletely) sketched out what would be required, but we're a fair ways away from that. And so far there has been virtually no interest in moving things in a direction to support things like that inside Bitcoin.

With the rest of your post you seem to be describing a closed cartel system for mining--  if we have that, why not dispense with the mining, trust it to keep the ledger... (and call it paypal?). Centralized systems are much more efficient and easier to make reliable. I think Bitcoin's (unique) value derives almost exclusively from not being centralized.


499  Bitcoin / Bitcoin Discussion / Re: Why blockchains might want to consider using AT "Turing complete" txs on: October 28, 2014, 08:49:48 PM
Doesn't splitting every operation into micro-operations and feeding the result to the VM solve the issue?
For simplistic implementations, yes (though you have to get it right). High performance ones... not really. For high performance you really want to hoist the boundary checking.

I'm not sure what advantage this system really offers over Moxie... as moxie is deployed and has toolchain support.

In general, I worry that this kind of system is too low level for a consensus system-- e.g. getting high performance will require dangerous complex execution enviroments; but it's an interesting domain. It also has no facility for dead code elimination, or other facilities which are more obvious when you understand the difference between with script does in a consensus system... that it's not really performing computation, but verification of computation.
500  Bitcoin / Development & Technical Discussion / Re: Miner accepting non-standard txs required! on: October 28, 2014, 08:21:00 PM
I feel sorry to see the referral code disclosed outside of the intended community. This pushtx is experimental only for our partner and our weibo followers. We do not currently replace conflicting transactions to prevent potential double spend. Don't worry. Thanks.
Is the source code available to see exactly what transactions f2pool will accept under this interface?  (Eligius' node code is available).

Quote
We do not currently replace conflicting transactions to prevent potential double spend. Don't worry. Thanks
If you accept transactions other nodes will not accept it still facilitates double spending, somewhat. The attacker sends a non-relaying transaction to you first, then floods the network with another transaction.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 201 »
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!