grandaire

ethereum, had a python version, but they abandoned it to concentrate on C++ (alethzero/ethminer) and Go (geth)

How long is it typically for a pump and dump cycle?

less than a day
1 day
10 days
30 days

I've being reading a lot about dapps, ethereum and counterparty. Just wondering since counterparty ported serpent to bitcoin and have it working, has anyone actually written any dapps that are useful?

I know I'm probably being very simplistic, as I'm pretty new to blockchains and you are humouring me, so thanks for that. I do appreciate your time and patience.

Data Output (OP_RETURN) don't have any inputs or outputs right? Anyway, probably easier just to make it a transaction which sends coins back to the same address, so not zero input/output, inputs being same as outputs, send to self

Transaction fees

I was kind of thinking of hierarchical deterministic wallets (BIP0032/BIP0044), one of the children keys being the one stored live and seed key being used to publish the "block intent to move"

Yes I would.

Wouldn't use it for everything, just as I don't now, but I would use it for some transactions.

Use case: People and companies like Bitstamp (and me) who want to have monies in hot wallet and are happy to forgo instant transactions in some of their wallets, in the interest of extra security and a chance to stop transactions within a certain timeframe. Like a half way house in terms of security between an offline wallet and a hot wallet. Works by forcing certain types of wallets to include a zero output zero input transaction in the blockchain a certain range of blocks before notifying its 'intent to move' funds from the wallet. This allows the owner of the wallet a chance to use a second key to insert a second zero input transaction to block 'intent to move'.

Glossary
Warm Wallet - Type of wallet which requires that transactions are flagged a certain number of blocks ahead of inclusion in the chain
Intent to Move - Zero input, zero output transaction which is included in the block chain, the only purpose of which is to validate the content of a subsequent transaction which must occur within a finite number of blocks.
Intent to move block - zero input, zero output transaction which is included in the block chain, the only purpose of which is to negate a 'intent to move' transaction. High priority transaction with high transaction fee

Description: Special type of wallet, transactions of which can only be processed if a transaction notification has being included in the blockchain X numbers of blocks before, but transaction notification cancellation has not. Presuming 10 block interval, transaction which will achieve the actual transfer must happen between 10 and 20 blocks after the notice of 'intent to move'.

Scenario 1 - Normal case
Example: On block 40 transaction is issued indicating intent to move 100 BTC from warm wallet WW to hot wallet HH.
On block 51 transaction moving 100 BTC from WW to HH is confirmed and funds transferred.

Scenario 2 - Stolen key
Example: On block 40 transaction is issued indicating intent to move 100 BTC from warm wallet WW to hacker wallet HK.
On block 45 real owner of the wallet notices the unauthorized intent to move transaction and issues a 'block intent to move' transaction with 0.001 transaction fee (high priority). An external service could be monitoring the blockchain and notifying users of warm wallets, of 'intent to move' transactions. On block 52 hacker attempts to move 100 BTC from WW to HK, transaction is rejected as miners see 'block intent to move' in block 45.

Scenario 3 - Late move
Example: On block 40 transaction is issued indicating intent to move 100 BTC from warm wallet WW to hot wallet HH.
On block 61 transaction moving 100 BTC from WW to HH is rejected as valid intent to move has not being included in the last 20 blocks. User told to try again.

Scenario 4 - Stolen key slow reaction
Example: On block 40 transaction is issued indicating intent to move 100 BTC from warm wallet WW to hacker wallet HK.
On block 52 hacker moves 100 BTC from WW to HK which is confirmed and funds are transferred.
Real owner of the wallet lost their money.

Actually just reading through your response again.

"If a mining pool doesn't see the second signature in time, what happens when they eventually include the transaction in a block (after X blocks have occurred)?"
If the transaction has not being included after delay + validity period blocks it should be disguarded. So for example if you had a 36 block (6 hour) delay wallet you could also have a validity period, so that if it was not included within the subsequent Y blocks it would be marked as invalid.

"How would this be different from a mining pool refusing to honor the second signature and including the transaction in a block (after X blocks), or would it be different?"
So I think you talking about a mining pool colluding with the hacker? If this did happen, you would be no worse off than today. But its fairly unlikely.

"Couldn't an attacker eat up all of the memory (or disk space) of the mining pools by generating these transactions as fast as they can so that the pools need to store millions of transactions that aren't ready to be confirmed, and then transmitting the "cancel" signature before the deadline?"
The 'cancel' action could consume a transaction fee to prevent this abuse?

Thanks Danny for the reply. Some excellent points and exactly what I was looking for. I've locked the other topic.

On your points, you are absolutely right, what I suggested would not work, for exactly the reasons you highlighted. But the use case still exists - will try and think of something else.

just thinking for the moment. Wonder is there a need?

I think probably if it was something that was generally a good idea and not done before I'd email the dev group and then maybe propose a BIP (I think thats the recommended process?). I am a developer (but not on bitcoin or altcoin so far) but don't want to waste my time/their time or embarrass myself if its been done already or is not useful for some reason I'm not aware of.

Would it be possible to have a new type of wallet, that was a type of multisig wallet. Delayed transaction multisig wallet.

Use case: People and companies like Bitstamp who want to have monies in hot wallet and are happy to forgo instant transactions in some of their wallets, in the interest of extra security and a chance to undo transactions within a certain timeframe. Like a half way house in terms of security between an offline wallet and a hot wallet.

Transactions initiated with this type of wallet would not be executed immediately, but would always be marked for processing, in X blocks (36 for 6 hour delay, 72 for 12, 144 for a day). The ability to "post date" transactions is already built into bitcoin, so would just be a matter of having a special case of multisig to throw transactions out of the pending pool if they were counter signed, as opposed to validating them if they were countersigned.

If the owner of the wallet noticed that an undesired transaction had being placed, they would have time to use a separate signature to mark the transaction as invalid.

Background ----
Bitstamp seem to have being doing everything quite well, keeping most of the funds in offline wallets. The money that was stolen was from a hot wallet. Petty cash, if you like, which they would understandably need to have easily accessible and in a hot wallet for operational reasons. Its a pain to have to transfer funds from cold storage frequently, but insecure to keep too much in a hot wallet.

Is it possible?

You would have a different wallet for that. So you would transfer from your delayed multisig wallet into your instant hot wallet as much as you think you might need in the next couple of hours.

If you allowed special 'fast' address, the hacker could just do the same.

Thinking about MtGx and particularly Bitstamp. Maybe there is a need for a new type of wallet.

Bitstamp seem to have being doing everything quite well, keeping most of the funds in offline wallets. The money that was hacked was from a hot wallet. Petty cash, if you like, which they would understandably need to have easily accessible and in a hot wallet for operational reasons.

But did it need to be an 'instant' hot wallet?

What if we had a new type of wallet, that was a type of multisig wallet. Delayed transaction multisig wallet.

Transactions initiated with this type of wallet would not be executed immediately, but would always be marked for processing, in X blocks (36 for 6 hour delay, 72 for 12, 144 for a day). The ability to post date transactions is already built into bitcoin, so would just be a matter of having a special case of multisig.

If the owner of the wallet noticed that an undesired transaction had being placed, they would be able to use a separate signature to mark the transaction as invalid.

Use case is for people and companies like Bitstamp who want to have monies in hot wallet and are happy to forgo instant transactions in their wallets, in the interest of extra security and a chance to undo transactions within a certain timeframe. Like a half way house in terms of security between an offline wallet and a hot wallet.

What do you think?

SSL doesnt run on port 80.

http://stason.org/TULARC/security/ssl-talk/3-4-What-ports-does-SSL-use.html#.VDlkM_ldXKA

But less pedantically, if people wanted to ban it, it would be much easier. Ban the entry and exit points and ban the ownership/dealing of it. Not to say it would be completely eradicated but would be limited to niche uses and a currency to succeed needs widespread adoption.

I don't think it will be banned though, just evolved and more regulated than currently. In general cryptocurrency is a good thing and will succeed in the longer term I think, nothing to be feared.

The ATM looked fairly clunky and a backwards step to me to be honest.Might be just because I'm comparing it to the normal ATM experience. The nfc on cash register looked handy, as did the person to person xfer. Not sure how suited to normal day to day transactions bitcoin is though.

Doesn't need to be profitable. Just needs to be worth while to eliminate a competitive threat. Have a look at some of the financial institution profits... I think I read somewhere to launch such an attack would be 500 million. Its really not much in that world

probably just a recycled email address. original one would have being cleared out after period of non use. Its just a troll looking for attention.

So to bring it all together...

0. new bug found in bitcoin core, which worries people
1. bitcoin value decreases
2. everyone rushes to spend them/convert back to Fiat
3. as prices drop miners profit gone so they abandon processing and shutdown operation
4. network becomes very susceptable to 50.1% attack
5. hacker/gloryhunter who wants to be the one to bring down bitcoin launches an attack (or anyone/any company whose interests are threatented by bitcoin success)
6. alternative cryto PoS or PoW which isn't susceptable to centralisation problems reboots the system
7. alternative is more widely spread in terms of ownership and more secure
8. off we go again

Absolutely, didnt mean to imply PoS wasn't a success.

Just googling Ethereum PoS PoW, I think you might be right. They might be a hybrid proof of work system, with elements of Pos design to avoid the centralisation problem.

http://www.reddit.com/r/ethereum/comments/23k1kg/why_did_ethereum_choose_to_use_proof_of_work_as/

Very interesting thoughts, thanks for taking the time to express. Definitely feasible I think, especially when combined with "People not spending BTC" and the resultant apathy/loss of interest exaserbated by a falling price.


Interesting article here on PoS system downsides.

"However, proof of stake, as implemented in nearly every currency so far, has one fundamental flaw: as one prominent Bitcoin developer put it, “there’s nothing at stake”."

https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/

Must admit I didn't understand all of it but!!!! I get the general gist I think. Do you think Ethereum could be the PoS system that suceeds?