Most of them are not taking away mining but, rather, adding more side-rewards for miners, since they can be merged-mined right alongside bitcoin. So they are extra little perks like when you happen upon a bunch of other minerals or metals while mining a mineral or metal.
Correct. Once the initial merged mining pool server setup is created and tested, it is very easy to add new merge-mined alt-chains. Pool users get extra rewards, with no extra work on their own part. This does not detract from the earlier poster's point that alt-chains are generally worthless or scammy or both. |
|
|
|
The reason I'm not a fan of PGP is because you need to install separate software, create separate keys, upload them to key servers, and keep backups of your keys. These are all things you already have to do with Bitcoin, anyway (or your BTC wallet service does for you). Blockchain.info and the Satoshi clients provide very simple signing already as part of your wallet. It's not as prominent, but I am hoping that will change, with big SIGN and VERIFY buttons clearly visible.
Yes, this sign-message capability is available via the GUI interface or RPC API. ECDSA signatures and keys also tend to be smaller than PGP-used forms. That was one reason why Satoshi chose ECDSA. And, double plug, distributed bonds and smart property use bitcoin signatures already. |
|
|
|
In Satoshi client every object can be serialized either to disk or to network.
Nevertheless I haven't found any difference between the serialization of the blockchain for SER_DISK compared to SER_NETWORK.
What classes are sensitive to SER_* serialization ?
I'm writing a Bitcoinj class to read and process Satoshi blockchain (blk*.dat) files and I want to know if I should care about SET_* flags.
The python implementation pynode does not have any notion of serialization differences between the two, either. pynode successfully imports bitcoin-generated blk000?.dat files, as well as talking on the network. Perhaps this was for future expansion? I would love to know any differences, myself. |
|
|
|
A major component of this is distributed bonds. One implementation, pybond, should have basic distributed bonds working within a week or two. With distributed bonds, you don't have to worry about your exchange going under, and taking all the bonds with you. Anyone with software that reads the distributed bond format may set up an exchange. |
|
|
|
Did GLBSE ever verify the identity of Pirate40 ?
Why would we verify pirate40? He never listed listed anything on GLBSE. How are we supposed to verify people who don't even use our platform? So why was GLBSE brought up in this topic ? Same reason BFL was, the guy mentioned us in passing when asking about pirate. Hardly. BFL was mentioned because the OP is an ass who wants to make trouble. GLBSE is a reasonable target for a Ponzi investigation, as it was a vehicle for making investment in Pirate very easy (via PPT's). Mind you I'm not claiming GLBSE is guilty of anything... just noting that reasonable people can understand why GLBSE is receiving attention from Ponzi investigators. |
|
|
|
Did GLBSE ever verify the identity of Pirate40 ?
Why would we verify pirate40? He never listed listed anything on GLBSE. How are we supposed to verify people who don't even use our platform? So why was GLBSE brought up in this topic ? Because of all the pirate pass-through bonds that were listed on GLBSE, one presumes. Gotta investigate, to determine if GLBSE was a "front" or "enabler" for Pirate's BS&T. |
|
|
|
Two people want to exchange cars, Alice owns Honda CRV and Bob owns Toyota RAV4. Honda CRV represented by 1 satoshi at 1qwe... Toyota RAV4 represented by 1 satoshi at 1rty... Bob and Alice construct single transaction to exchange cars: Inputs: 1 satoshi from 1qwe... 1 satoshi from 1rty... Ouputs: 1 satoshi to 1asd... (address owned by Alice) 1 satoshi to 1fgh... (address owned by Bob) Is it possible to know what car owned by Alice, or did I misunderstand the statement that exchanged items has to be a part of the same transaction? They are done as part of the same transaction.
See the rules for colored coins, linked above. |
|
|
|
But what if a person wants to exchange one car for another, and both of them represented by the same amount of bitcoins lets say 1 satoshi, creating single transaction would make it impossible to tell who owns what. ECDSA keys provably demonstrate who owns what. It uses the same technology as the rest of bitcoin. |
|
|
|
JFYI... we currently own two single family homes, right next door to each other. We are trying to sell the smaller of the two, but renting it out has crossed our minds. Many of our friends are landlords, too: young, a little bit of financial headroom, own 1-2 properties. The main thing that stops us? Being landlords to our neighbors. Two data points: 1) My story: About a decade ago, when I was a renter, I lived next door to my landlord, who seemed a very reasonable fellow. Late one night, I heard banging on our door. It was the landlord's girlfriend, who had just been beaten by the landlord. We protected her, called the police, who came and carted the landlord off to jail. The next day, the landlord was out... and served us immediately with eviction papers. It was a fraudulent eviction, I called our sexy attack dog lawyer, and things got legally nasty for a while. 2) Friends' anecdotes: As a landlord, they say, you will eventually evict someone. It is inevitable. Therefore, - Follow eviction procedures in the lease to the letter. Do not give second chances, accept partial payments, etc. or they will bite you in court.
- If you rent to friends, remember you may have to evict that friend.
- If you live near the property, you have to live near someone who hates you, for kicking you out of "their home."
So go for it... as long as you are not next door neighbors to your renters. |
|
|
|
Can any of the devs provide any technical insights on where these limits are coming from?
Inaba is correct about the database access needing multi-threading, or to be more technically correct, database access needs more than one database client connection running in parallel. Ditto for downstream bitcoind access -- pushpool should probably contact a farm of bitcoind's, not just one. |
|
|
|
It's just inconvenient for the issuers to require an underlying satoshi for each assets, because the divisibility of their issued assets and the maximum quantity of them that can issue depend directly on the divisibility of bitcoin itself. Doesn't seem so elegant to me.
Speaking as someone who is implementing this right now... it is very elegant. One of the rules that will be encoded into pybond is - A bond (a colored coin / smartcoin) is never zero-value (nValue==0 in CTxOut)
Thus the value is intentionally dependent on bitcoin. It raises the cost of creating each bond above zero, thereby creating an incentive to be conservative with your bond / smart property issuance. It also serves as a fee signal (it is required to pay a fee to transfer tiny amounts of bitcoins), further discouraging spam and flooding, and encouraging efficiency. 1000 bonds requires a minimum of 1000 satoshis. A value of 3 satoshis may mean (this is bond-dependent) that the holder carries 3 bonds. |
|
|
|
Very nice tool. Am I correct that this could be the basis of a tool to monitor large numbers of addresses for activity?
Sure. It could monitor whatever metrics you need, on the bitcoin network. |
|
|
|
Wondering if an Electrum client might be able to modified to talk to a pynode ... or vice versa?
What does Electrum use to talk to bitcoind? pynode provides a JSON-RPC HTTP server interface, just like bitcoind... |
|
|
|
|
Longpolling is a very elegant and useful... hack. It is a hack because HTTP clients typically initiate requests, and elicit server responses. This HTTP client behavior does not cover server-initiated messages that the client is not expecting.
Longpolling says "wait, until the next server-initiated message to me"
Most custom designed protocols support server-to-client asynchronous messages, so there is no need for the hack.
|
|
|
|
|
Thanks to socrates1024, pynode got a much needed upgrade from python's asyncore to the more modern gevent.
This opens the door to easy multi-peer operation, so expect full node status very soon.
|
|
|
|
This seems like a fair criticism. There are two parts to a typical bond transfer,
1) Owner #10 must create and sign a well formed BOND message to Owner #11
2) Owner #11 must create and sign bitcoins to Owner #10
They are done as part of the same transaction. P2P bonds are based on smart property, this page has detailed protocol descriptions that may make things clearer: https://en.bitcoin.it/wiki/Smart_PropertyYep, SIGHASH_ALL was the bit I was missing. Looks 100% possible to do this, indeed. |
|
|
|
SIGHASH_ALL is the default which is why it's not mentioned. There are descriptions of the SIGHASH flags in the theory section of the contracts page: https://en.bitcoin.it/wiki/ContractsSIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, are signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".
Yeah, tucked into a bit of a corner it is, away from other documentation on signatures and scripts. Might warrant its own page, or at least a reference from the Scripts page, for an enterprising volunteer. Anyway, it definitely works for this purpose, solving the problem. |
|
|
|
|
It sounds like SIGHASH_ALL is the hidden magic solution, that prevents parties from reordering or tampering.
Edited example accordingly.
Documentation on SIGHASH_*, particularly on the wiki, is severely lacking.
|
|
|
|
Certainly it is part of the same transaction. Let us adapt the example from the Smart Property thread: Definitionsprevious-txout 0: "smartcoin", standard send-to-pubkeyhash, nvalue==1 b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c,0 previous txout 1: normal transaction, standard send-to-pubkeyhash, nvalue==100000 7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730,0 smartcoin seller pubkey for to-be-sent smartcoin (CK) pubkey destination for smartcoin payment (SK) smartcoin required price (P): 100000 smartcoin buyer pubkey for to-be-spent payment (PK) pubkey destination for smartcoin (BK) Round 1, smartcoin buyer and seller agree on a transactionPresumably the smartcoin seller has <somehow> advertised for sale smartcoin b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c,0 at price P. Presumably, the buyer knows how to create a standard 2 txin, 2 txout format transaction that the seller expects. The buyer and seller communicating this basic information is outside the scope of this discussion. Round 2, smartcoin buyer creates incomplete TX, sends to sellertxin 0 (smartcoin transfer) prevout (b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c, 0) scriptSig = zero-length (null) txin 1 (payment transfer) prevout (7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730, 0) scriptSig = <PK-derived signature> <PK>, SIGHASH_ALL txout 0 nValue = 1 scriptPubKey = OP_DUP OP_HASH160 hash<BK> OP_EQUALVERIFY OP_CHECKSIG txout 1 nValue = 100000 scriptPubKey = OP_DUP OP_HASH160 hash<SK> OP_EQUALVERIFY OP_CHECKSIG Round 3, smartcoin seller signs TX, and broadcasts completed TX to networktxin 0 (smartcoin transfer) prevout (b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c, 0) scriptSig = <CK-derived signature> <CK>, SIGHASH_ALL txin 1 (payment transfer) prevout (7d865e959b2466918c9863afca942d0fb89d7c9ac0c99bafc3749504ded97730, 0) scriptSig = <PK-derived signature> <PK>, SIGHASH_ALL txout 0 nValue = 1 scriptPubKey = OP_DUP OP_HASH160 hash<BK> OP_EQUALVERIFY OP_CHECKSIG txout 1 nValue = 100000 scriptPubKey = OP_DUP OP_HASH160 hash<SK> OP_EQUALVERIFY OP_CHECKSIG DiscussionPotential attacks, neither resulting in a direct loss of value: - Buyer may stall or refuse to send incomplete transaction (wasting seller's time and DoS'ing an issue, if the seller prevents other buyers from attempting purchases in parallel)
- Seller may stall or refuse to send completed transaction (wasting a buyer's time and leaving the fate of their coins unknown)
|
|
|
|
There is one weak point here: you have to trust that the owner of a correctly-attributed bond key will actually construct a valid (protocol wise) bond transaction that transfers control to the owner_pubkey you requested. Given that you're also trusting this person to repay the bond, this is not necessarily a big deal, but it'd be nice to require it.
You have to trust the issuer of a bond to repay it, but you should not have to trust the previous (or any other) owner in any capacity. This seems like a fair criticism. There are two parts to a typical bond transfer, 1) Owner #10 must create and sign a well formed BOND message to Owner #11 2) Owner #11 must create and sign bitcoins to Owner #10 Each party is holding something of value, and wants to trade for the other thing. What does game theory say?  Each party's action may be instantly validated, but who goes first? At this juncture, perhaps some readers may be directed to the just-created Atomic Coin Swapping thread, if they have helpful ideas. |
|
|
|
|
Show Posts
