Bitcoin Forum
July 07, 2024, 01:08:06 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][PRESALE] Robries -Blockchain with Zero Waste and Recycle to Save The World on: October 25, 2018, 12:06:20 PM
interesting idea, converting plastic waste into something more useful like "3d printing fillament".
I hope this project can be successful

Greetings from Kalimantan
2  Alternate cryptocurrencies / Bounties (Altcoins) / Re: [AIRDROP] PLANEX - 2 375 000 tokens rewards!!! on: August 06, 2018, 03:14:38 PM
Proof of joined post
Telegram username:  @aisazz21bitrace
twitter username:  @latregetic
facebook url:  www.facebook.com/fs1
ETH wallet address: 0x74D481AaE9dbaB952acd19Fbe7Fb9C7419A3A9ea
3  Alternate cryptocurrencies / Altcoin Discussion / Re: What Should I do as a newbie? on: February 12, 2018, 04:53:48 PM
Helo, i am a newbie too in this field. Hope we will can survive here
4  Bitcoin / Development & Technical Discussion / Re: Designing distributed contracts on: May 21, 2011, 10:10:56 PM
I was thinking actually that the bets would be programmatically enforced.

I just remembered that online betting is illegal in the USA. It's probably best to not have direct technical support for it in the block chain unless that situation changes. It wouldn't add very much beyond what can already be done with multi-pay transactions, anyway.

It's not just the bets, anything that you could use an impartial oracle to arbitrate are potentially up for contract.  Mostly short sells and price hedges.  These are technically gambling, but since it's a futures market, it's such a grey area that I don't think anyone would give a shit.  

Also, if the US government actually notices Bitcoin, we're probably going to get hit with a lot of laundering charges, not online gambling charges.


Also, I see this as the ability for the network to have an internal method of creating enforceable transactions for potentially large sums of money.  When the only thing you have is a Bitcoin address and possibly an IP, even with a 3rd party community they have a reputation with, there is an incentive to cheat.  Having a neutral 3rd party able to reverse the transaction after arbitration removes that ability to cheat, or at least makes it much harder to do.
5  Bitcoin / Development & Technical Discussion / Re: Designing distributed contracts on: May 21, 2011, 05:56:28 PM
Lots of tricky problems to solve there and, frankly, not that many people interested in doing it. So I think dispute mediators along with most other Bitcoin-related service companies will be strongly identified for the foreseeable future.
That's my guess as well.  An address associated with the company, and publicly shown on the website is all a mediation agency would really need to do.  Still technically anonymous from the perspective of someone trying to find a name and address, but to the community, they can build substantial reputation, so long as they use that address.

Quote
Is it possible to have multiple mediating parties involved in the transaction.

Yes, I think so. It involves an addition to the multi-pay protocol, which is already quite complex. I doubt it would be a very popular feature. This type of escrow is useful for the little guys who just want to buy some alpaca socks. Cases where the risk of corruption is so high you need 3 mediators are almost certainly high-value transactions between legally accountable organizations, so if it goes wrong you can just go to court.
My major concern is high value arbitrage and hedging between major parties.  Both parties would need to be legal entities in a position to sue each other with a reasonable chance of recovering losses.  A hedge fund in the cayman islands isn't going to give two shits about a suit someone sends them from China.  And many hedge and arbitrage transactions could be in the tens of thousands of dollars.  Being able to compromise the mediator for even one of these transactions could be worth the effort of breaking into his or her systems.  If the client is able to offer a high security 3 mediator transaction for these people, you'll probably see a lot more capital influx, because most of the attack vectors associated with a single mediator would fail misserably with 3.

Quote
How would you be able to invoke a fair oracle without the ability for one party or the other to influence or abuse the thing?

The oracle can be checked at any point to ensure its answers are correct. As long as there's some reasonable flow of transactions that rely on it, that should make cheating difficult or un-interesting.

I don't know all the details. I'm still pondering how to do it. I think the oracle would have to vend partially signed transactions on demand that match an output script checking the answer. It might be possible to settle bets that can be represented numerically this way.
Yeah, I could see a gribble style oracle script that would give you MtGox price quotes if you feed it the right bit of script.  As long as there is some 3rd party tool that allows for the bet/script to be made into plain English for the purposes of the bet, that kind of oracle could act as an impartial arbitrator of short sells. 
6  Bitcoin / Development & Technical Discussion / Re: Designing distributed contracts on: May 21, 2011, 03:11:08 PM
Yeah, the anonymity of the mediator would run counter to the mediator's ability to prove he's trustworthy to the community.

I see the escrow transactions as a way to make transactions that are not self-reinforcing, basically any transaction that requires any kind of trust between the parties, work out for the parties involved.  When there is no way for any reasonable person to trust the other part, there needs to be a mechanism to stop cheating on both sides of the deal.

There will always be exchanges and markets that have their own internal methods of dealing with fraud and arbitrating disputes, but having a mechanism built into the block chain that allows a transaction to take place that does not involve only BTC transfers is a very powerful tool.

The meet in the middle protocol would work best, but some method of fairly assigning a mediator would be necessary.  If it just picks the first one on the list, then there is an incentive for mediators to spend huge quantities of time generating addresses with a very high number of leading zeros, such that they are always first in line to collect that 0.002 BTC fee. 

Is it possible to have multiple mediating parties involved in the transaction, such that a majority of the parties have to agree with one course of action in order for that action to be seen as valid by the network?  If you could choose 3 mediation agents from a list of agents with a positive reputation, practically any attack requires compromising too many agents for it to be viable.

How would you be able to invoke a fair oracle without the ability for one party or the other to influence or abuse the thing?  I guess there are a lot of services you could poll gribble style to see what MtGox closed at last night to officiate the bet.  Hell, having some kind of limited oracle support would be a very handy thing to allow for automatic and automated short sells of BTC on the market.

How hard would it be to develop a working design document that could be presented to one of the developers? 
7  Bitcoin / Development & Technical Discussion / Re: Managing substantial changes to Bitcoin - a QA network. on: May 20, 2011, 12:10:05 PM
It would still be a good idea to have an implementation spec in place for a hash algorithm switchover.  Ideally you want to be running a hash system that has no known vulnerabilities, and the ability to seamlessly and very quickly switch from one hash system to another.  It doesn't take a lot of work to completely kill people's trust in a currency, especially one that relies of crypto voodoo to work.  Much like the Fukushima disaster, all you have to do is yell loud enough that X uses Y, and Y is (whatever), therefore X is (whatever) in order for most people to believe it.  The ability to go "oh shit", notify everyone, and collectively vote to switch would be a very powerful way to mitigate that effect.

Code the protocol such that:
If 26 of the last 40 blocks have the 'use new hash' toggled to yes, then every to-spec miner and the official client will ignore all blocks not using the new hash from block 26 onwards.  Clients can read both block types, and transact in both block types, because this was pushed potentially years before it was needed.  And once there is a discovered vulnerability, the miners can decide for themselves as a group if they should transition to the newer, harder hash system.
8  Bitcoin / Development & Technical Discussion / Re: Designing distributed contracts on: May 20, 2011, 11:51:29 AM
This will be crucial to the future of the currency.  The current biggest downside to the currency is the fact that there is no possible remediation if you get scammed in a trade or purchase.  Every address can be a unique string, and there is no possible way to trace who owned that address.  Without some way to create a contract, there is no way to avoid this issue.

By being able to create a contract that is enforced by the network itself, allows for very complicated forms of behavior with a very minimal chance of being cheated.  Unless the buyer or seller are actively colluding with the mediator, there is no way to actively scam.  However, without some kind of mechanism to insure the mediators stay honest, there is no way to stop that from happening.  Unless the cost to become a mediator is greater than the profits derived from scamming, scammers will simply become a mediator on an alternate ID, and steal every transaction they take part in.

If both buyer and seller have to agree on the escrow agent, then there are less chances of either side being screwed in the event of shenanigans, but having to individually negotiate that for every purchase takes a lot of time and limits the ability of the seller to make automatic sales.  If the seller has a list of preferred mediators, then the onus for mediator selection is on the buyer, and that lessens the cost of the seller's side, but the buyer might end up running into an elaborate scam.  Many mediation firms have a very strong incentive to side with the company that paid/referred to them, in the interests of repeat business.

In order to assure fairness, or at least limit fly-by-night mediation sites with fancy web pages and no real there needs to be a mediator escrow fee, such that the total value of the outstanding contracts they are acting as a mediating agent on is less than some value they have in escrow in the network.  It could be a proportional model, like fractional banking, but there needs to be some strong financial incentive to not be a jerk.



Potential Attack Vectors (that I can think of now):
Respected Mediator is corrupt, buys tons of stuff from online guys using a 30 day contract with himself as the mediator.  Voids all the contracts after the goods arrive.  Seller is screwed.
Mediation site is hacked, and the private keys it used for mediation are stolen.  Now the hackers are able to buy tons of online merchandise from people that use that service, and void the contracts once the merchandise is delivered.
Seller only allows one mediation service, which will collude with them on some contracts.  Seller takes money, never sends package, and the mediator validates the contract without any input from the buyer.

You might want to include a mechanism for voiding a set of keys used in a transaction.  If the mediator notices the intrusion, there needs to be a way to tell the network 'These keys are invalid, never ever use them, ever.'  There should also be a way to freeze contracts that used those keys in such a way that is fair to both the buyer and seller.  I'm not sure how you'd do that with a compromised mediation agent, but it is possible to use any odd number of mediators such that the buyer or seller, plus the majority of the mediation agents concur in order to void or enforce the contract.

Now that I think about it, having multiple mediators, as long as the keys all don't end up in the hands of one of the two parties, would eliminate most of the mediator related attacks.
9  Bitcoin / Mining / Re: FPGA mining for fun and profit on: May 17, 2011, 06:01:19 PM
It's a bit easier now, though still not very cheap.  You can hand the team FPGA files and they'll turn it into an ASIC.  The only way to make it cost effective per chip though is to get a run of 10k+ or so or tooling costs will kill you.


Yeah, if 5 years from now you had several companies doing the block generation as a business model where they collect the tips, then you would probably see a big rackmount box packed to the brim with ASIC logic in order to drive the per transaction cost down low enough to still make a profit.
10  Bitcoin / Mining / Re: FPGA mining for fun and profit on: May 17, 2011, 05:49:25 PM
Custom ASICs are retarded expensive.  I know the NSA/Some universities got them for DES/Triple DES encryption key breaking, but they cost a few million to develop, and were never in large enough demand to make the non recoverable engineering costs low enough on a per chip basis.
11  Bitcoin / Mining / Re: FPGA mining for fun and profit on: May 17, 2011, 05:40:19 PM
Well I stand corrected, and was hilariously off base on my values.  This is still a pretty awesome business plan to run on idle FPGA clusters that would otherwise sit there doing nothing.  The marginal cost is pretty much zero since the hardware was purchased for something else and the depreciation expense is borne by someone else.
12  Bitcoin / Mining / Re: FPGA mining for fun and profit on: May 17, 2011, 04:57:31 PM
Apologies but no more development information will be posted.  I've been offered a 25% share from someone that owns 2 FPGA clusters.  If you haven't seen that type of hardware before think a 156 FPGAs per machine.

I had a feeling this is what would happen.

Can you at least give us the rough specs of the clusters, so I can ballpark about how many Gh/sec you'll end up pulling?  If they're machines like this, then you're probably going to be pulling anywhere from 500Gh/sec to 5.5 Th/sec per machine.  If it's a small cluster of perhaps 24 machines used for cryptographic attacks and research, then that one cluster will probably end up with more compute power than the entire rest of the network. 

Man, now I want to dig out my old Spartan 3 fpga board and see if I can get a working hash engine out of it just for giggles.



For people who don't know a ton about FPGA stuff, you can run a hash engine natively in hardware using a hew hundred gates at most for MD5, and run one hash per clock cycle, with a clock speed of 5-550 Mhz.  Most of these chips have anywhere from 2000 gates for the barest of bare bones $50 DIY kits to about 9 million on the latest Virtex 7. 

Assuming the hash engine took 350 gates (2 orders of magnitude reliable), the chip runs at 550 MHz, and has 9 million gates, and was just 20% efficient, that is 80% of the time the chip is waiting for data or or otherwise not hashing, you could see about 2.8 trillion hashes per second.  TRILLION HASHES PER SECOND.  Even using worst case figures, a 5 million gate device at 250 Mhz, 5000 gates per hash engine, and a 5% utilization factor, you still get 50 Gh/sec, over 200 times the hash calculating power of a Ati Radeon 5850.

Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!