Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Smart Contract Security Field Guide

scsfg.io

Post reply on HN
Print view View original

121–130 of 156 posts

Re: Smart Contract Security Field Guide

#121

Post by snapcaster »

trompetenaccoun wrote: post #98
jjordan wrote: post #30

Earlier quoted context omitted.

Arguably the most popular use case is that smart contracts are used to create decentralized exchange services. See: Uniswap. They are also used extensively in the crypto sub-genre called DeFi, or decentralized finance. One of the most popular implementations is called Aave, which allows one to take loans out (i.e. give the contract Ether as collateral, receive an amount of USD stablecoin in return) on a given set of…

For the record NFTs get a bad reputation because the public associates them with silly pictures traded for outrageous prices. However NFT simply means that the token itself is not fungible and can therefore be used to refer to something specific that does not have to be art at all. Tickets would be an example that multiple teams are working on using the same tech, although they may not refer to it as NFT because the…

Ticketing is already fully digital and no blockchains or NFTs were required. This is AGAIN another example that people bring up where blockchain solves none of the relevant problems and they've ALREADY BEEN SOLVED WITHOUT CRYPTO

Re: Smart Contract Security Field Guide

#122

Post by chrisco255 »

theamk wrote: post #72
chrisco255 wrote: post #60

Earlier quoted context omitted.

They may be willing to accept trusting the dollar-backed token issuer. In the case of USDC, it's Circle. But there's nothing stopping JPMorgan, BoA, Wells Fargo, Western Union, etc implementing their own dollar backed tokens, and I suspect we'll see more and more of that as regulatory clarity settles. Maybe the Fed themselves will issue tokens in this way. It's also entirely possible to construct a permissioned, yet…

Your first and last sentence contradict to each other. If you already have a third party which both sender and receiver of money can trust, what's the point of blockchain?

There are hundreds of use cases for it. We are discussing one in particular which is for international settlement of USD backed tokens with limited trust assumptions necessary. Because we are talking about USD and not BTC or ETH, there is ALWAYS an intermediary involved in any transaction that is not paper cash in hand.

The sender and receiver still benefit from a permissionless, automated, international, instant transfer of funds with a cryptographically certified audit trail. The blockchain runs 24/7 and has no downtime. A token can be fully programmed and fine tuned for whatever parameters need to be checked to authorize a transfer. Those rules are transparent and auditable to everyone involved.

The transfer goes through within seconds and the cost of the transfer does not scale with the value of the transfer.

Re: Smart Contract Security Field Guide

#123

Post by photonthug »

hn_throwaway_99 wrote: post #114
photonthug wrote: post #113

Earlier quoted context omitted.

Final will and testament: When I'm dead, move all the money from account A into account B. What is "not feasible" about a government API that answers whether a citizen is alive and a banking API that runs a funds transfer? Let's stick the code for this in some large cloud provider where it checks the credentials and conditions involved every minute. We could debate whether this is a cheaper/easier/safer approach than…

Because what you are describing is not a smart contract, at least how it is nearly always commonly understood. What you are describing is simple API automation. Nobody describes what IFTTT or Zapier can do as a smart contract, yet that is literally exactly what you have described.

>Because what you are describing is not a smart contract, at least how it is nearly always commonly understood.

Shrug. So now we've moved through your criticisms of "it's not possible" and "it's not useful", and we're splitting hairs about whether it's in the right category. It seems like you want to have a conversation where "smart contracts" means exactly/only Ethereum as it exists today. If you're asking about the use-cases of abstract technology, and then pivot to insist that discussion revolves around existing brands/implementations, it feels like you're moving the goal-posts. You're of course free to insist that smart-contracts ARE ethereum and vice versa, but ironically when you do that you're a clear victim of marketing, and you're essentially endorsing the branding that you claim to dislike!

If "mere API automation" is disqualified as "smart contracts" according to your definitions because it isn't blockchainy enough, and if everything that IS blockchainy is disqualified as stupid or a scam, then I guess you win debates before they start. But that's just not a very interesting conversation for any one else.

FWIW, ethereum does have a concept of oracles ( https://ethereum.org/en/developers/docs/oracles/ ). I wonder if ethereum and zapier did have a lovechild, would you call it a smart-contract then? Do we need the contract AND the decision-data AND the assets to be blockchained, or can we blockchain a subset and still call it a smart-contract?

A mix between zapier, plus something like ethereum, together with legislation that requires open-APIs for critical services is probably exactly what we need to satisfy tons of practical real world use-cases. That's what you claimed to be interested in, right?

Re: Smart Contract Security Field Guide

#124

Post by photonthug »

jeffbee wrote: post #77
samuellevy wrote: post #68

Earlier quoted context omitted.

More than just needing an oracle - the keys and the house are both physical items. There's not really any practical way for a contract on the blockchain to validate that a particular physical item is in fact the item that it purports to be. Are these ACTUALLY the keys to this house? Are they the only set? The original set? Were the locks changed, and this set in the contract is no longer valid? Then putting aside all…

Thinking of a real estate transaction as an exchange of physical things is already a mistake. Most people expect to take possession of a structure in most deals, but it is sort of beside the point. What you're trading is a legal filing where you go to the county recorder (most states) and just claim to own something. What are you really buying? The promise from the other guy that they won't claim to own it in the fut…

> In a legal system this vague, smart contracts simply do not have a niche.

This is an interesting point. The way I think about this is, if we can ignore for a second the bitcoin-related baggage of smart-contracts as a concept, then there's still a lot of overlap with related concepts like open government and automated legal reasoning. So I'm curious if you think of those things as also intractable. Also, blockchain isn't some magic wand that replaces the need for other datastructures. Why should partial or even doubtful ownership be impossible to model and do secure/verifiable/conditional compute on?

Re: Smart Contract Security Field Guide

#125

Post by hn_throwaway_99 »

photonthug wrote: post #123
hn_throwaway_99 wrote: post #114

Earlier quoted context omitted.

Because what you are describing is not a smart contract, at least how it is nearly always commonly understood. What you are describing is simple API automation. Nobody describes what IFTTT or Zapier can do as a smart contract, yet that is literally exactly what you have described.

>Because what you are describing is not a smart contract, at least how it is nearly always commonly understood. Shrug. So now we've moved through your criticisms of "it's not possible" and "it's not useful", and we're splitting hairs about whether it's in the right category. It seems like you want to have a conversation where "smart contracts" means exactly/only Ethereum as it exists today. If you're asking about the…

This conversation has probably been the biggest waste of time I've ever had on HN. "Moving the goalposts"??? This whole thread is on an article titles "Smart Contract Security Field Guide". To be clear, what you are talking about has absolutely nothing to do with the concept of smart contracts as discussed in that article, and honestly I have never heard someone in the past 10 years or so discuss smart contracts in a way that doesn't include distributed consensus. It has very little to do with ethereum specifics, but if you want "smart contract" to mean any automated behavior, then sure.

Feel free to call a giraffe a dog and then get upset when people point out that nobody else calls that thing a dog.

Re: Smart Contract Security Field Guide

#126

Post by TimJRobinson »

karpierz wrote: post #55
brobinson wrote: post #52

Earlier quoted context omitted.

You don't need to trust when you can verify. The source code for the intermediary bank (smart contract) would be available for everyone to read.

I'm not talking about code. The goal of the transaction is for the Spanish bank to have access to USD. In the example given, the Spanish bank would then have to take the crypto it got and trust an exchange to give it USD in exchange for the crypto. How do you get USD to the Spanish bank without trusting a third party?

There are many USD stablecoins they can use: https://www.coingecko.com/en/categories/stablecoins. The top two are the most liquid but are also centralized, many of the others are fully decentralized.

Re: Smart Contract Security Field Guide

#127

Post by DropInIn »

photonthug wrote: post #91
duxup wrote: post #46

Earlier quoted context omitted.

One theory I have about all this is that doing deals with zero trust is that ... people don't want to do that ... and no matter what you do there's going to be this whole process around these transactions to provide some assurances and so on. On the surface all this title company stuff is silly and it is, unless there's a real problem with the title and then you want it. These are human problems.

These sound like problems I associate with bureaucracy, not people, and problems that just go away if/when some kind of API is provided. If the purpose of the title company or lawyer or whatever is to do something like "phone the county office clerk and tell them to look up a rubber stamp and fax us a signed copy", then it's not like it's impossible to get rid of the middlemen.

But its not _worth_ getting rid of the middle man when the fee is so much higher than current processes, on transactions where it might actually be used.

It really is a solution in search of a problem.

Re: Smart Contract Security Field Guide

#128

Post by DropInIn »

latchkey wrote: post #53
jjordan wrote: post #30

Earlier quoted context omitted.

Arguably the most popular use case is that smart contracts are used to create decentralized exchange services. See: Uniswap. They are also used extensively in the crypto sub-genre called DeFi, or decentralized finance. One of the most popular implementations is called Aave, which allows one to take loans out (i.e. give the contract Ether as collateral, receive an amount of USD stablecoin in return) on a given set of…

This answer right here is, in my opinion, one of the most interesting use cases that is available today. Provide collateral and take out a loan against that collateral. It allows people to act as their own bank. No longer do you have to go to a bank, ask for permission and then get approved for a loan. Now, you can do that yourself, instantly, without any trouble at all. Amazing really. What are those loans used for…

Who is providing the finance and under what terms? How does rhat actually differ from banks or one of the many microfinance services predating crypto?

Now, the real kicker, what is the effective cost when _all_ fees are included, because someone has to pay for it and when combining the interest of non-traditional lenders and such fees I highly doubt it'll be cheaper.

Re: Smart Contract Security Field Guide

#129

Post by DropInIn »

duxup wrote: post #36
mteigers wrote: post #35

Earlier quoted context omitted.

I have no direct affiliation with this service (nor am I a user of it) but I recently learned about "Pool Together" which is a "lossless" lottery system. It's a daily lottery that happens automatically, you do not need to collect as it happens automatically, and you can withdraw all of your capital at any time. I thought that was a decently novel use case.

That sounds amusing ... albeit the lottery aspect makes me suspect shenanigans. Is anyone reading the contract to understand if it really is what it says it is? One of those issues is of course that people will need to find someone who can read the contract for them, and hope they get it right. Still, good example that is easy to get, seems like easy to code and work.

Such a "lottery" is effectively a trillion dollar rug pull in waiting....

Re: Smart Contract Security Field Guide

#130

Post by latchkey »

DropInIn wrote: post #128
latchkey wrote: post #53

Earlier quoted context omitted.

This answer right here is, in my opinion, one of the most interesting use cases that is available today. Provide collateral and take out a loan against that collateral. It allows people to act as their own bank. No longer do you have to go to a bank, ask for permission and then get approved for a loan. Now, you can do that yourself, instantly, without any trouble at all. Amazing really. What are those loans used for…

Who is providing the finance and under what terms? How does rhat actually differ from banks or one of the many microfinance services predating crypto? Now, the real kicker, what is the effective cost when _all_ fees are included, because someone has to pay for it and when combining the interest of non-traditional lenders and such fees I highly doubt it'll be cheaper.

These are collateralized loans that are automated with "smart" contracts. Programmable money.

Who? Anyone who wants to provide liquidity. Is this different from existing solutions? Yes and no, the difference is that there is no human intervention here... you don't have to ask for permission. You're also dealing with a global pool of funds using open source technology, instead of just a single bank or service.

The only additional "fees" above the interest rate are the cost of a transaction on the block chain. There are certainly a lot fewer hands in the pot and overhead.

Learn more at one of the largest and oldest sites: https://aave.com

Post reply on HN