Show Posts
|
Pages: [1]
|
Quick question, that I'm having trouble finding in the official documentation. What happens to the child transactions when their parents expire in the mempool? For example say you three un-mined transactions in the mempool. TxC spends the outputs of TxA and TxB:
Transaction A <-----_------ Transaction C Transaction B <----/
Now let's say Transaction A is evicted from the mempool for being around too long without getting mined. Is Bitcoin Core "smart" enough to realize that Transaction C is now unspendable? I.e. will it evict it along with A, right away? (Thus unlocking Transaction B to be spent somewhere else?) Or will it wait for Transaction C to stick around the full 72 hours?
|
|
|
Great. Thanks a lot. Will stick with python-bitcoinlib. (Much prefer python to JS.) Just wanted to make sure I wasn't picking something that was already or about to go out of date.
Thanks again!
|
|
|
I'm looking to write an application that needs low-level control over custom transactions. Stuff not covered by out-of-the-box wallets. I see a number of libraries out there, but no real general consensus about the relative strengths and weaknesses. I'm fairly language agnostic, and prefer just to use the best library.
Was looking at python-bitcoinlib, but as of late it doesn't look to be actively maintained. Prefer to use a library that's likely not to become deprecated in the near future. Also looked at Bitcore, but I don't need browser support, so don't really have much to gain from the pain-in-the-ass of dealing with Javascript. Any opinions on BitcoinJ or just directly using Bitcoin Core?
Mostly just trying to get a sense of state-of-the-art/best-practices here. I'd hate to start developing against some library, then find out that there was a much better alternative two months down the road.
Thanks.
|
|
|
Let's say Alice and Bob want to run a Tontine contract. Every alternating day either Alice or Bob is required to send 1 BTC into the Tontine public address. After Alice sends 1 BTC, Bob has 144 blocks (24 hours at 1 block every 10 minutes) to send his payment.
Then vice versa, and so on until one misses their deposit. Let's say its Bob. After 144 blocks of non-payment, the Tontine pays Alice the reward: the entire sum of payments made over the lifetime of the contract. Is there anyway to do this with Bitcoin's existing protocol (assume no new OpCodes or primitives added to the underlying protocol)?
Unlike other types of smart contracts, Alice and Bob specifically don't want the contract to unwind. E.g. cross-chain atomic swaps rely on TimedHashLocks. If one party doesn't pay up their obligations, then the timed lock expires and the other party gets their funds back. But in a Tontine, we specifically want to avoid this issue. Otherwise once Bob goes broke, he could just bail and get his payments back.
|
|
|
I've been toying with the idea of autonomous bitcoin wallets. That is certain public key addresses that will always exhibit some behavior. A simple example might be a bitcoin wallet that always sends its entire contents to another pre-defined wallet every 24 hours.
In something like Ethereum this would be easy. Just create a smart contract. But say all parties insist on bitcoin, it's a little more challenging. Script is notably *not* Turing complete, so the complexity of possible pre-committed behaviors is pretty limited. However I still think autonomous wallets of arbitrary complexity can be created by using off-chain ZK-SNARKs. Here's how:
Alice wants to create an autonomous forwarding wallet like above. She writes a ZK-SNARK function, as an input it accepts a valid full block chain and the public key of a wallet. The function goes through the entire chain, consolidates all the existing transactions leading into the autonomous wallet, then outputs a transaction to send those to the pre-determined destination wallet. Alice publishes the function for anyone to inspect and test themselves.
Now Alice creates a public/private key conforming to the autonomous wallet. She cryptographically signs the above ZK-SNARK function, and provably destroys the private key. No one can generate transactions for the wallet besides the ZK-SNARK function. She publishes the signed function. If Bob wants to use the forwarding wallet, he can send BTC. Then Bob uses the function to generate a signed forwarding transaction, which he publishes to the network. As long as at least one person uses the ZK-SNARK function per block update, the wallet is guaranteed to forward its entire contents from the last block. If multiple people use the function, it's no issue. Duplicate transactions will do the same thing, and miners will just randomly pick one to add to the chain.
Advantages of this scheme: Most important, it allows for a lot more power than using Bitcoin Script. The autonomous wallets are Turing complete. It is run entirely off-chain, no need to shoehorn complex transaction logic into the limited transaction space that Bitcoin allows. If you want certain behavior, you don't have to wait for a BIP adding the needed opcode. Very complex systems can be evaluated only limited by the computing power of the users. It's completely trustless besides for the destruction of the private key. Anyone can inspect the function, and even run it on mock inputs (without signing the transactions).
Disadvantages: You have to trust that the private key was destroyed, otherwise Alice has backdoor access. Another disadvantage is it doesn't allow any state to be preserved between block updates, besides what's committed to the blockchain. This limits the possibility of persistence across times. One way to pass small amounts of data between block updates, would be to use encoded messages in the transaction. The generated outputs also need to be idempotent for each block update. If both Bob and Charlie run the function, the miners could arbitrarily pick which of their transaction to commit to the network. Finally it requires at least one person to run and publish the function per each block update, whereas Script is automatically processed within block updates.
So any opinions on this? I'm still a crypto-coin neophyte, so I could easily be making a mistake? Or am I re-inveting the wheel here? I couldn't find really any pre-existing literature on this specific topic. A lot of people talk about ZK-SNARKs for Ethereum or ZCash, but no one to create autonomous Bitcoin wallets or self-executing trustless Bitcoin contracts.
|
|
|
|