Topic: [white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain - page 7. (Read 24217 times)

that's right friend and as a result we all benefit - we can't all code , but coders can't EVER make marketable ideas either , so i wouldn't call it management so much as a Handshake.

and to Poor Etlase2 (nervous ASIC investor )  i'm actually being up front and trying to give the coders the credit, and more stake than myself (more likely)  otherwise i'd just wait until its made , find an average C++ coder to copy paste it and release it , and the sad thing would be,  that it would be more successful than the original product , but with no credit.

so i see that as nefarious that's why i opened the topic.  

what you need to see is that IF i have a successful design its at least AS valuable as the code.

because as i said, go write some super code and release it on usenet.  :- \

: )  

best way to look at it,  is that its going to happen, i'm going to do it anyhow , so why not try to get the coders in on it , that actually wrote it ?

that way we all benefit - if i'm a good designer they benefit if they are a good coder I benefit - but look around , do i really NEED good code? lol

i'd prefer it but !  

I guess you call such people managers

The guy whose idea is to take others' ideas and have someone else code them is lol'ing?

lol

+1

have opened a topic based on this BC idea and making a design from it with the NVC core code Balthazar is on board :

https://bitcointalksearch.org/topic/ann-a-new-design-based-on-nvc-powpos-and-incorporating-the-mini-blockchain-199952

feel free to contribute !  I can make this big.

No, most people are just not convinced to your design. Guess you just have to take this risk and become billionaire then.

Real world success defined as "market cap of 100 dollars"! What happened to the whole risk vs. reward that bitcoin proponents champion as the reason why early adopters deserve billions of potential dollars for their "smart, early investing"? Seems like most people in reality are scared little girls.

I guess it's theory vs reality. Making a coin with proven bitcoin design and only change in database structure is doable and with limited risk. Making your complicated design from scratch requires a much more work and is far more risky. That is why it will probably remain just in theory while other currencies will improve one step a time with real world success.

Funny how people keep coming up with ideas that are in decrits though and believe each individual idea deserves its own coin. Also funny how convoluted ideas are coming up to fix the problems that are already resolved or don't exist in decrits. I guess some people just need their hands held? Which is better for cryptocurrency in general: 400 different and flawed currencies that each solve 1 problem, or 1 currency that solves them all? I guess it just depends on your pov.

And that is? [Decrits doesn't count. It is so complicated that is even hard to grasp not to mention implementing]

I'm referring to the duplication of data and/or hash required to verify if you already have a tx that a peer is offering. When a connected peer says "hey do u have this tx?" he must send a 32-byte hash in bitcoin. When whichever type of block comes through, intra-peers must send at least a 32-byte hash (again, bitcoin doesn't even do this, it sends the full tx, but it could be a hash). Using what I suggested, only 3-6 bytes need to be sent to know if you have the tx or not. Multiply this by tens or hundreds of txes per second times the number of connected peers, and it is a huge data savings that is not available to bitcoin.


Ah, an interesting proposal.


Uhh, you need to do more studying on how bitcoin changes have been proposed and adopted then. It is in the hands of 3 or 4 people. Sure it's painless when you only need to get a cartel of miners on board.


:shrug: You are rationalizing a whole lot of stuff to provide for fast transactions when it can already be accomplished a better way. And all of this rests on the users being required to do something to help merchants. Merchants can't really force them or expect them to do it. "Advanced" features should be a power-user only thing, otherwise you have millions of people with accounts that have special features that is costing time and bandwidth for everyone to keep track of.

I am a coder but not good enough in C++ to implement my idea with sufficient quality (at least not fast), but I could efficiently communicate with developers. I am good at design and have good understanding of economics and business so I keep in my mind that my design need to have some strong selling points to be success. It's true I am not good at selling things to public, making hype etc

Coin design can be separated in 3 parts:
1) Designing db protocol (account balances, transaction etc)
2) Design efficient network security algorithm (Current bitcoin PoW scheme is too expensive )
3) Make sure proper economic incentives are present during bootstraping and when coin matures.

These can be discussed independently, so I don't see a point in publishing new coin design until all 3 parts are ready. Now I have good ideas for 1) and 3) but my idea for 2) needs some discussion. I don't see a point in publishing new coin idea before all 3 parts are sufficiently polished.

why don't you announce a Topic for the feasibility of another new design based around this principal, -

in the end this whole market is coder rich with the shittiest understanding of economics i have ever seen i my life, and that's doesn't even start to touch on socioeconomic principals,  but in the end that's completley to be expected.

Im here to make a good code "available" to Joe on the street -

The problem is someone like myself thinks so radically different to a coder, but a Coder feels like they "own" the product and for good reason, they essentially do.

But where i can step back and say , i will not even attempt to get involved in Coding , for some reason Coders have a bit of a breakdown where they can't step back and say "i'm a fucking useless at communicating these ideas to thew general public" 

so it's all for nothing, as i said its not just good enough to have THE BEST design, that gets you 50% there.

lucky but for coders I'm waiting to see which is the best then I'll promptly get any coder that will agree with my market design to copy paste it and we can release something.

when my design leaves this forum, no one will say "that was a copy of bla bla" - but full credit will of course go to them.

so why not make a topic about a new "coin" based on this , i'll try to get some coders on board. i'll make it if you like ! ?

I don't understand. In account tree transaction don't have to reference any other transactions. It only reference accounts with version. Transaction in this system should look something like
(trx_version, offsetSender, offsetReceiver, senderVersion, amount, signature)
(1 + 5 + 5 + 5 + 8 ) ~ 24 bytes + signature don't know how long it needs to be.

I think it should be longer to allow some meaningful descriptions for end users like 'for yesterday dinner', etc..
In proposed system nothing stops you from generating new address for every transaction like in bitcoin and I really don't think goal of system should be that every transaction is anonymous. Making anonymous transactions available is enough.

What I meant is attaching name to account. Not making this name unique and allowing users to send funds to it.

I am aware of that. Changes need to be included along with new software revisions. Bitcoin proves consensus can be reached and such changes can be made painless. No need to in network voting system for that.

Not really. It can be automated in client. You just setup your fast payments account. Specify maximum fast payment size you need and software automatically keep this account balance on required level. If you deplete this sub account to much it is automatically refilled. No user attention is required after setup.
If you need to cancel this account you can always do full account withdrawal which would take something like 2x time of normal confirmation (this is sufficient delay for limit change operation).

It's a big imposition on the user, it's also a transaction which is going to have to have a tx fee. Whenever they have to make a payment for more than the amount, they will have to wait for multiple blocks to have the full tx approved. If they want to change it, it's another tx. Etc. It's also not necessary in a good proof-of-consensus system.

In addition to this, 32-byte hashes are not necessary to verify receipt of previous transactions. Peers who have not even communicated with each other before can reference transactions like so:

[timestamp - 4 bytes for each second]
[2-4 bytes of account offset, depending on what is most useful based on transaction activity - 2-4 bytes once for each tx that shares this offset]
[remaining 1-3 bytes for account offset]+[1 byte pseudo-hash]

The 1 byte pseudo-hash could be bigger, but it limits one account to 256 transactions per second, although the client will have to be aware of pseudo-hash collisions. When Visa is only like 4,000 transactions per second, this can't be that big of an issue. So the maximum one transaction could cost in wasted bandwidth is 10 bytes, but on a busy network, most transactions will only cost around 3 bytes to verify receipt or reference it with another peer. This is presuming my initial idea of using timestamps to identify specific transactions. It also allows for an easy way to locate transactions in the transaction block chain, though this is going into my design, but it's the one I know. *shrug*

Although bitcoin could use some protocol tweaking, it still *at best* has to send 32 bytes, but right now just goes ahead and wastes the full 300 bytes or whatever a typical tx is. 32 bytes->3 bytes on a busy network is gigabytes saved daily per node.


8 bytes I think is an ideal number that allows for setting up a receipt/order system/identity proof. I think bank-like intermediaries (preferably anonymous ones, but that is technology that has to be proposed and advanced outside the network) will be commonly used to preserve anonymity. Account ledgers have some caveats that they are slightly less anonymous than pseudotransactions a la bitcoin. Reusing account numbers needs to be encouraged by lower transaction fees, because it is in the interest of the health of the network. If there are intermediaries that provide you with 8-byte mini-addresses, you can preserve that anonymity completely from everyone except the bank, unless there are ways to provide this anonymously in the future. Those who want bitcoin's pseudonymity can still do it, but tx fees will be higher.


This is considered part of bitcoin's pseudonymity as only you and the receiver know which part of the tx is the payment and which is the change. But we all know that bitcoin isn't all that anonymous, and with an account ledger making things even trickier, the idea of pseudonymity needs to be redressed.


I had this idea for early encoin proposals, but I don't like it because it will create a rush of custom address stealing. If businesses are public on the chain, users can associate the addresses manually. If they use intermediaries, this could still be addressed with using business->user account numbers in the tx message.


Easy peasy stuff with a ledger. Gotta make sure to have "master" keys that can change those account options, not the accounts themselves. Keep the master key cold and let the hot wallet do its work without fear of a total catastrophe if there is an incident.


Yes, but there needs to be a process of acceptance for this. Say, a voting system. Even if account types are just complex uses of the scripting system, to save the data required to store these simply (and to make sure everyone has the exact same ledger), the account "types" need to be defined and everyone needs to agree on it.


Anyone who plans on reusing a custom transaction could set a custom transaction type up themselves, basically a script-hash storage system. Then it could reference the custom type in a tx and only supply the variables needed to suit the script-hash, saving data. Of course there have to be fees to store this stuff, but people who use the same script-hash a lot could save money on a fee-per-function type tx fee.

A somewhat out-there possibility is to have a proof-of-work storage function. Small networks could use the ledger's proof-of-work (or proof-of-consensus) as a timestamping service and have the final say on the order of that network's events.

I have some other ideas somewhere, but it would require digging up really old notes.

Secure 0-confirmation small transactions

Concept of accounts with withdrawal limit go me thinking and I think it enables implementation of secure 0-confirmation small payments. By small I mean small relative to your account balance which can make it applicable in even big transactions in absolute terms.
First let me outline how limited accounts could work.

1) Send to network special transaction to modify withdrawal limit for your account. You specify limit as number of coins per no of blocks. Such change will take effect in eg. 100 blocks (delay is important for my idea)
2) Network accepts transaction and after 100 blocks it will reject any transaction that would cause specified limit to be exceeded. Miner node will accept first transaction for withdraw and when he receives another which would cause limit to be exceed he queues it until first one is included in block and limit is available again.

How could limits prevent double spending? Double spending is possible because you can send one transaction to merchant while simultaneously send another one to miners which moves all your coins to other address. But with limits you cannot send all your coins at once and this can help secure merchant transaction.

Suppose you have 100 coins in your account with withdrawal limit of 1 coin per block. If you want to send secure 0-confirmation transaction for 1 coin you sign a transaction to send 1 coin to merchant valid if included in one of next 10 blocks (or whatever amount of confirmations is deemed secure).
Now even if attacker tries to double spend his coins in alternative blockchain he would only be able to move 1 coin from his accounts per block, so event if his network branch is accepted as longest merchant transaction will still be valid and included in some of later block. To successfully make doublespend attacker would need to make 10 blocks alternative branch in secret which is infeasible.
If my reasoning is valid merchant can ensure he will receive funds by:
1) Checking that there is no pending withdraw limit change on sending account
2) Check that sending account balance is high enough so it can't be emptied to fast.
3) Ensure transaction that pays to him has propagated enough in network and that it is on top of queue (checking few respected mining pools is enough)
That should complete in seconds.

Do you see any problems with this idea?

Idea is to keep constant number of recent blocks (for example 5000) so if transaction volume increases mini blockchain will grow in size but it won't hurt security.

interesting

Interesting idea, implementation may be difficult though. Also, what happens far, far into the future, let's imagine this is adopted, won't a large number of transactions mean that previous records are being overwritten at an ever increasing pace, eventually leading to a serious security problem?

Let's consider some new awesome possibilities that arises when we get rid of bitcoin scripts and adopt account tree, so this thread won't die off.

Transactions

1) Smaller transactions - transactions could use just account tree offsets instead of addresses / public keys. We can address more accounts than we will probably ever need with 5 bytes. Addresses takes 25 bytes and public keys 65 bytes.
2) Including messages in transactions. We don't need to store transactions indefinitely so we can permit short messages attached to payments (eg. order id). This would improve user experience a lot.
3) We can get rid of sending change back to ourselfs because we can spend any amount of bitcoin from our account.

Accounts
We will store accounts in nice separate cells in db, so we can make different types of accounts as needed.
Fore example:

1) Accounts with descriptions. We can allow attaching custom names to account eg. 'Payment address for shop.example.com'. This description could be presented to users paying to this address. Huge user experience boost.
2) Multi signature accounts. We can make accounts with multiple pubkeys attached and require M of N signatures to spend from this address.
3) Limited accounts. We can define maximum withdrawal limits per time period for accounts.
4) We can extend account types if needed. This system is actually more powerful than bitcoin scripts (we can always make accounts with scripts).

Feel free to extend this list.