Bitcoin Forum
May 20, 2019, 06:11:18 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Alternate cryptocurrencies / Altcoin Discussion / Re: ZEN PROTOCOL, is good platform to use-- open for discussion! on: November 17, 2017, 07:39:24 PM
Zen Protocol have a ANN Thread?

It does now.
2  Bitcoin / Development & Technical Discussion / Re: locktime on: January 11, 2015, 10:33:52 PM

But, please, PLEASE answer my question in post #12. It's much more urgent to me than this discussion about transaction replacement.

As far as I can tell, you're correct. The terminology for transactions you call "OK" and "Not OK" is "final" and "non-final." One wrinkle is that there was some divergent behaviour in the testnet, where non-final transactions (nLockTime in future & sequence number < UINT_MAX) were being accepted but not replaced. This was fixed just a few days ago.

In any case: there is no code in Bitcoin Core to replace transactions based on sequence number, and mainnet nodes don't accept non-final transactions into the mempool.

Oh yeah, and a non-final transaction can't be included in a block until it turns final. It makes the block invalid, which will fork anyone who accepts it off the blockchain.
3  Bitcoin / Development & Technical Discussion / Re: locktime on: January 10, 2015, 11:14:23 PM
any more.
There was some code stubbed out to do that, but it was never implemented as far as I recall. Do you have a reason to believe they actually were? (if you don't I don't want to waste time spelunking through old code)

That was an inaccuracy on my part, sorry. The commit removing the code indicates that it never worked.

Edit: The wiki was linking to the wrong commit stubbing out transaction replacement. This is the real commit.
4  Bitcoin / Development & Technical Discussion / Re: locktime on: January 10, 2015, 10:54:54 PM
How does the current Bitcoin software deal with sequence numbers that are not 0xffffffff? Is every value for the sequence number accepted? If a miner receives double-spends with different sequence numbers (all with zero confirmations), will it choose the one with the highest sequence number for inclusion in a block?

It seems that the "microtransaction channel" implementation in bitcoinj always uses sequence number 0 for to-be-updated transactions. Is this the recommended way of setting the sequence number?

Transactions don't get replaced in the client based on sequence number any more. More recently, the handling of nLockTime was also changed, so that transactions with an nLockTime in the future can't enter the memory pool. There's some history at the wiki.

I posted an idea for payment channels to the bitcoin-development list yesterday, provoking a discussion of this very topic.
5  Bitcoin / Development & Technical Discussion / Re: Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY on: January 09, 2015, 11:45:48 AM
FWIW I'd recommend reposting this to the bitcoin-development mailing list - it'll get more review there. (I personally would prefer to reply there myself)

Thanks just posted there.
6  Bitcoin / Development & Technical Discussion / Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY on: January 08, 2015, 02:46:57 PM
Background: micropayment channels, OP_CHECKLOCKTIMEVERIFY

A micropayment channel lets you set up a channel over which you can send small payments to a second party, without putting all those payments on the blockchain. The simplest version of the idea uses an initial deposit transaction to a 2-of-2 multisig address, and nLockTime to create a refund of that deposit that can only be spent in the future. Then you can directly send the payment receiver transactions with an earlier nLockTime and that refund you slightly less. Only the payment receiver can add their own signature to the last transaction and claim the total amount you sent them.

One problem here is that transaction mutability may let the payment receiver alter the deposit transaction in such a way that the refund transaction is invalid, which means you must trust the receiver in the setup phase. CHECKLOCKTIMEVERIFY (listed as BIP 65) would solve this this by adding a locktime check to Bitcoin Script itself, allowing you to make a deposit transaction to a P2SH address that inherently permits you to sign your own refund transaction at some future time, in addition to a 2-of-2 multisig lock that requires both you and the payment receiver to add one signature.

A limitation of this sort of channel is that payments flow only in one direction. This is because the payment receiver can sign any transaction you send them, not just the most recent one, and so it's possible to just sign the transaction transferring the largest amount into their control. This is easily remedied by opening a second payment channel in the opposite direction, but now both parties have to deposit funds over the lifetime of the two channels. If one party doesn't know ahead of time whether or not the other party will go into credit, having only one channel may save the use of a deposit.

I propose a way of using CHECKLOCKTIMEVERIFY to allow a reversible payment channel, introducing at most one additional broadcast transaction, with a waiting period before the payment receiver can access deposited funds. The extra transaction and waiting period apply only when the depositor doesn't co-operate with the receiver.

In this protocol, the setup is identical, with a deposit made to a P2SH address matching a script allowing either single-party+CHECKLOCKTIME or 2-of-2. In this case, however, all payments made by the depositor occur in the form of unbroadcast transactions to special holding addresses.

These holding addresses are themselves P2SH addresses, with scripts known to both parties. Each script may be redeemed in one of two ways:
  • by the payment receiver, using a CHECKLOCKTIME restriction that expires some period of time after the restriction on the depositor's refund transaction, or
  • by the depositor, using their own signature, together with a hashlock.

In the second case, we actually use a double hashlock, i.e. the depositor must provide a value which when SHA256-hashed twice produces the value in the script.

The receiver generates these values according to the following algorithm: Beginning with a secret S0, they double hash S0 to make the hashlock value for the first payment, D0 =H(H(S0)). Then to make Si+1 given Si, they create a public nonce, Ni, and let Si+1 = H(Ni | H(Si)), where a|b denotes the string a followed by the string b. The hashlock values Di are not secret, and can be disclosed in advance or as part of the process of receiving the associated payment.

When the receiver wants to refund some amount to the depositor, the receiver finds the last payment which left the depositor with a balance greater than the desired balance, and negotiates a rewind of the payment sequence to that point, with an additional payment of the remainder by the depositor. Suppose the last payment that will remain valid was the i-th payment, counting from zero. The receiver creates a new nonce, N'i, creates the associated new secret value S'i+1 by S'i+1 = H(N'i | H(Si)), and sends D'i+1 to the depositor with a request for payment of the right amount. This amount will be greater than that associated to Di, but less than that associated to Di+1, so the depositor does not need to trust the receiver in order to honour the request. The payment chain is now forked at Di, with a branch Di+1, Di+2... and a branch that only has D'i+1. The receiver now unwinds the old branch, back to Di, by revealing Si+1 to the depositor. The depositor can now generate - and check - the secrets Si+1, Si+2..., and so knows that if the receiver attempts to sign and broadcast a transaction to an address using one of those secrets, the depositor can take back all their funds before the receiver is able to put their own (CHECKLOCKTIME restricted) transaction from that address on the blockchain. Now the best usable payment to the receiver is the one associated to D'i+'.

When the two parties want to close the payment channel, one party signs a transaction from the deposit address to whatever addresses are desired, and sends the transaction to the other party to add their own signature and publish. This avoids either party having to wait for CHECKLOCKTIME restrictions to expire. If either party abandons the protocol at this point, the other can use the CHECKLOCKTIME restrictions to ensure they get at least as much as they would if both cooperated. Note that the holding addresses are only used on the blockchain when the protocol is abandoned.

This protocol does not deal with the case of malicious attacks on a party's network connection, which could keep them offline until CHECKLOCKTIME has expired. This is something that each party should consider when choosing how long the restrictions should be in place for. The protocol improves on blueadept's use of a new nLockTime for each reverse payment, by keeping the wait time independent of the number of payments, and not requiring either party to predict ahead of time how many payments will occur.
7  Bitcoin / Development & Technical Discussion / Re: Is this 16-of-16 multisig tx redeemable under current bitcoin implementation? on: March 27, 2014, 03:22:48 PM

"scriptSig": "OP_FALSE 3045022100d2e8211aa4c5ae6c0bb7c0082e7e76cdb216d6279c11c0bb740e512697dbf8ec02205 fb2380372d8cc851ec6a54cf054df3c423352c837d50478aa12bbeafe93337301 OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP OP_DUP",

How about using OP_2DUP and OP_3DUP to reduce the number of opcodes?
8  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official on: March 23, 2014, 07:21:31 PM
I still don't see what mastercoin is doing about this ....

Mastercoin needs more than 80bytes in OP_RETURN for asset issuance. Theirs seems to be a different problem.

On the other hand, a regular mastercoin send only takes about 30-35 bytes. Maybe Counterparty could consider selectively sending common, small transactions with OP_RETURN, and using multi-sig only for relatively unusual transaction types?

By the way, thanks both to my mysterious benefactor and to whoever thinks I'm Satoshi. I'm not sure my previous comment merits either of those compliments, but I appreciate them. My SX stealth address is SghSgpVgk7yAFx91DxwfE84Dm6r2hwSpMWcFJbR9wQTAv7pgq61Nx3dNsn if anyone is interested - and if they are, I'm sure they can send me a nonce without too much trouble  Smiley
9  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official on: March 23, 2014, 03:40:58 AM
Let's have some figures, shall we? Tarsnap charges 300 picodollars / byte-month. Assume ten thousand full nodes with their own blockchain, that's 3 microdollars / byte-month, or 3*12*80 microdollars / year = 0.3 cents / year for 80 bytes. But of course the cost of storage falls exponentially, let's say a three year halving time; then the total lifetime cost for storing your 80 byte OP_RETURN on every full node in the Bitcoin network is given by the sum of a geometric series with first term 0.3 cents and common ratio 2^(-1/3).

That's a total cost of 1.5 cents. At current prices, and with the above generous assumptions made on behalf of miners and other full node operators, the correct maximum additional charge for a filled 80 byte OP_RETURN is 0.025 mBTC (it can be argued that the additional demand for Bitcoin created by permitting new uses is a driver of increased Bitcoin prices and thus should lead to a discount, but that's harder to quantify). So just set that as the default until floating mining fees are introduced in (hopefully) 0.10. Bitcoin users who don't want to "provide" that storage can go ahead and not run a full node.

The idea Luke-Jr raises occasionally of a social contract existing between Bitcoin node operators to store and process only financial transactions needs dealing with. Bear in mind that in his maximalist interpretation, absolute consensus between all node operators is morally required to change that contract. It falls through on several grounds, principally vagueness and lack of historical support. Vagueness we've seen in this thread: no-one is quite clear on what makes a transaction financial. Is a transaction transferring a currency other than Bitcoin part of the social contract? Is a transaction containing what is effectively routing data (c.f. stealth addresses) fully financial, or is the additional stuff an anonymity functionality not part of the social contract? And so on. As to historical support, allow me to quote from someone who would know:

The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

The thing is, Luke, that like it or not, Satoshi is/was a libertarian, and his creation embodied the 'take it or leave it' aspect of that political philosophy. Consensus means a consensus of mining power. Coordination means passing around proofs of work. If you feel that the amount of storage space the blockchain needs is too onerous to justify running your huge mining network, then by all means take your ball and go home, or for that matter start playing a different game - you have every right to reject whatever blocks you wish. Bitcoin will be just as pure as the majority of mining power wishes it to be.
10  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official on: March 23, 2014, 02:02:33 AM
We're not talking about forcing anyone to do anything. We're talking about the default relay policy for Bitcoin Core. If it were a matter of forcing anyone to do anything, why would a 40-byte OP_RETURN OK and not an 80-byte OP_RETURN (again, the original, publicly-announced, merged-into-the-codebase plan)?
40-byte OP_RETURN is potentially unavoidable for some things (no, I don't know any examples).

The answer is stealth addresses, which fit nicely in 40 bytes, are completely random by design (so are incompatible with semantic filtering) and add significant value to the network. I'd like to know why you are so engaged in this conversation, when you don't know about probably the most talked about use-case for the feature under discussion? In fact, why are you trying so hard to influence default relay policy, which has no direct effect on 'blockchain spam', when your aims would be better served by convincing other miners that you're right?
11  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN]Faircoin - The First Fairly Distributed COIN -Vote for us on exchanges! on: March 12, 2014, 01:58:36 PM
The addresses of the unsent and unrecoverable coins are easy to spot on the blockchain, right? So just issue a hard-forking update that makes those coins invalid. So long as those addresses are never used again, nothing will be different; if they 'mysteriously' come back to life, those transactions will never be confirmed because the vast majority of the mining power will be with the updated client which sees them as invalid and doesn't include them in the next mined block. It doesn't even require that all users upgrade.
12  Bitcoin / Legal / Re: Mt.Gox Multi-plaintiff Suit on: February 20, 2014, 08:14:14 PM
If a Japanese or American court orders MtGox not to enable withdrawals of BTC or fiat until they can prove they can cover all customers' deposits, then that is what MtGox will do. Someone just needs to convince a court to make that order. I would be shocked if a good lawyer couldn't make that case given that the collapse in price on MtGox is universally attributed to fear that they're not solvent.

As I said further up the thread, this is the clean option. The messy option is that USD holders get cashed out, MtGox declares it can't cover BTC deposits and becomes insolvent, and then everyone who withdrew fiat becomes a target for clawback based on the principle of unfair preference. If you're a USD holder, do you want to face a lawsuit or multiple lawsuits from the BTC holders?
13  Bitcoin / Legal / Re: Mt.Gox Class Action Suit on: February 20, 2014, 03:21:08 PM
Uncomfortable though it might be, holders of BTC on MtGox need to realise that their interests in a bankruptcy are fundamentally opposed to those of USD holders. The right thing to do for BTC holders is to file a second class action seeking to enjoin MtGox from allowing any withdrawals until it can prove it holds sufficient funds to cover both all USD and all BTC deposits.

MtGox has very short terms and conditions; go read them. They make exactly the same warranty on currency holdings and on Bitcoin holdings; thus in an insolvency the Bitcoin holders should seek equal preference. The USD holders would obviously seek to see their USD holdings cashed out before the BTC holders are even looked at, but that's terrible for the BTC holders. It's also very likely to be unfair preference.

What does that mean practically? That all the USD holders could end up with court orders to return their withdrawals.

Oh, and no cheeky conversion of BTC to USD at MtGox's rate, either. Holders of BTC are entitled to fair value. A marketplace in insolvency is by definition not a fair means of valuing assets.
14  Other / Beginners & Help / Re: Newbie restrictions on: June 20, 2011, 05:09:27 PM
This supports a theory I have that the behaviour of an online community is heavily influenced by the software it runs. So for example in a blog that runs WordPress with regular comments, everyone takes their lead from the blogger: if he's thoughtful and polite, so are they, if not, not. (The subject matter has an effect, but less than you might expect.) If he happens to be running Disqus comments, the blogger has less influence, because people lek for 'likes'. Metafilter (my favourite community site) uses a layout and moderation system that you won't find anywhere else, so the community is likewise unique. And 'forums', usually running either SMF or phpBB, all resemble each other in that

  • Lots of people talk smack
  • Even more people act very defensively
  • Many don't read more than three or four comments in the thread before they reply. I certainly haven't read all the comments in this one. A side effect is that there are more outright dumb comments, although intelligent ones may or may not exist alongside them.
  • Smileys everywhere
  • Mods make a lot of explicit rules and 'sticky' them stickying itself being particular to this sort of forum.
    • These rules become more arbitrary over time.
  • Your reputation is very visible and significant, thanks to the per-post sidebar on the left that says how many posts you've made, and even what 'title' you have.

Instituting a rule that people without established rep have to post in a forum that no-one, including the posters, reads, in order to prevent 'spam' the lurk requirement may reduce spam, but the posting requirement won't is a perfect example of this. Ironically when I attempted to post to another thread fifteen minutes ago it was in order to point out that Mark Karpeles' motto of "php can do ANYTHING!" should probably have tipped more people off that MtGox wasn't the most secure of sites. The way you talk, the way you code, the software you choose to run, all both say something about you and affect your actions and nature.
15  Bitcoin / Bitcoin Discussion / Re: What to call 0.001 BTC? (5 BTC Bounty) on: May 14, 2011, 08:24:25 PM
Millies, as a friendly form of millibitcoins.

I like it because it goes with Mikes, a friendly form of microbitcoins, and someone is sure to do a nice logo of Millie and Mike.

Why not let a thousandth of a Bitcoin be one Mill? Then 'Millies' can be the informal form.
16  Economy / Marketplace / Re: futures trading service on: April 26, 2011, 12:31:25 AM
Any broker or exchange that allows 5% initial margin is crazy. It might be OK in the extremely liquid forex markets that deal in well established currencies, but not in a market like Bitcoin/USD where the market depth can be measured in thousands of dollars. Rule of thumb, your margin shouldn't be of the same order of magnitude as the spread...
17  Economy / Economics / Re: The value spike... c'mon, you all noticed it! on: April 20, 2011, 11:56:10 PM
Bringing it back to the original topic: my first thought reading about the online poker indictments last week was that it would bump exchange rates on speculation that both money launderers and more legitimate poker players would at some point move to Bitcoin in volume. For this to fully explain the rise, though, would require insider knowledge of the indictments before they were unsealed.

That said, I'm definitely bullish on Bitcoin in the light of what's happened in the poker world.
Pages: [1]
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!